Aggressive Inlining - When it doesn't work ?

What is Inlining?

A process in which code is copied from one function directly in to the body of the another function (i.e. to the function which uses the code from the called function).

What are it's advantages?

• Stack is reduced i.e. variables need not be push and pop from the stack.
• Context specific optimization on the body of function is feasible.
• No function call or return call overhead needs to be maintained.

What is Aggressive Inlining?

JIT (Just In Time) compiler can logically determine which methods can be inlined. But at times, we know logic better than the compiler. Isn't it? So how do we force JIT compiler to perform the inlining? The answer is "Aggressive Inlining",

Syntax:

[MethodImpl(MethodImplOptions.AggressiveInlining)]

static int MethodName() { }

Name the scenarios, where Aggressive Inlining won't work?

• MarshalByRef : Since calls have to intercepted, executed and dispatched, MarshalByRef classes cannot be inlined.

• Virtual Calls : Since the end target of the call is unknown, this is ignored.

• Valuetypes : When valuetypes are passed as reference or when valuetypes are copied by compiler to avoid unexpected mutation.

• Virtual Machine(VM) Restrictions : JIT needs to seek permission from the VM to inline a method e.g. like in iOS this is just not possible as platform doesn't allow it.

• Complex Flowgraph : This includes complex loops or exception handling (try-catch) and similar scenarios.

Besides this, any security probe or non-native IL instructions are also out of scope of inlining.

Hope you learnt something new today. Happy Monday!

-