When is a method eligible to be inlined by the CLR?
Posted
by
Ani
on Stack Overflow
See other posts from Stack Overflow
or by Ani
Published on 2011-01-11T16:34:52Z
Indexed on
2011/01/11
18:53 UTC
Read the original article
Hit count: 236
I've observed a lot of "stack-introspective" code in applications, which often implicitly rely on their containing methods not being inlined for their correctness. Such methods commonly involve calls to:
MethodBase.GetCurrentMethod
Assembly.GetCallingAssembly
Assembly.GetExecutingAssembly
Now, I find the information surrounding these methods to be very confusing. I've heard that the run-time will not inline a method that calls GetCurrentMethod, but I can't find any documentation to that effect. I've seen posts on StackOverflow on several occasions, such as this one, indicating the CLR does not inline cross-assembly calls, but the GetCallingAssembly
documentation strongly indicates otherwise.
There's also the much-maligned [MethodImpl(MethodImpOptions.NoInlining)]
, but I am unsure if the CLR considers this to be a "request" or a "command."
Note that I am asking about inlining eligibility from the standpoint of contract, not about when current implementations of the JITter decline to consider methods because of implementation difficulties, or about when the JITter finally ends up choosing to inline an eligible method after assessing the trade-offs. I have read this and this, but they seem to be more focused on the last two points (there are passing mentions of MethodImpOptions.NoInlining and "exotic IL instructions", but these seem to be presented as heuristics rather than as obligations).
When is the CLR allowed to inline?
© Stack Overflow or respective owner