Are GetCallingAssembly() and GetExecutingAssembly() equally prone to JIT inlining?

Question

There's Assembly.GetExecutingAssembly() and Assembly.GetCallingAssembly(). Note that GetCallingAssembly() has a Remark mentioning that depending on how JIT inlining behaves it may be possible that one method is (or is not) inlined into another and so GetCallingAssembly() returns varying results.

Now how is GetExecutingAssembly() different? JIT inlining could technically inline the code that calls GetExecutingAssembly() and so that code now belongs to a different assembly and depending on whether that happened GetExecutingAssembly() can just as well produce varying results.

Why doesn't GetExecutingAssembly() description have remarks mentioning JIT inining similar to what GetCallingAssembly() description has?

It is of course one possibility that both are susceptible, and the comment should apply equally to both. — Marc Gravell, Oct 01 '12 at 08:11

score 17 · Accepted Answer · answered Oct 01 '12 at 08:39

The GetExecutingAssembly method is not susceptible to JIT inlining because of the same reason MethodBase.GetCurrentMethod is also not susceptible since they are implemented in a similar way.

Both methods declare a local variable of a special enumeration StackCrawlMark and initialize it to StackCrawlMark.LookForMyCaller. This local variable has the side effect of preventing the method calling into GetExecutingAssembly or GetCurrentMethod from being inlined which will then guarantee correct results.

This is supported by experimentation and also by the comment associated with this enumeration in the SSCLI20:

// declaring a local var of this enum type and passing it by ref 
// into a function that needs to do a stack crawl will both prevent inlining of 
// the calle and pass an ESP point to stack crawl to
//
// Declaring these in EH clauses is illegal; 
// they must declared in the main method body

The reason GetCallingAssembly is susceptible is because you're looking for the caller's caller and the local variable only guarantees that the caller is not inlined, which means that the grandparent method can be inlined leading to an unexpected result.

That would be a breaking change so I would have to say no. I went through the technical implementation details only to support the fact that a method that calls `GetExecutingAssembly` is guaranteed to not be inlined and that's why the warning is not present in its documentation. — João Angelo, Oct 01 '12 at 09:02

Are GetCallingAssembly() and GetExecutingAssembly() equally prone to JIT inlining?

1 Answers1

Linked