C# closure heap allocation happening at start of method

Question

I seem to have run into some odd behavior of the C# compiler.

Consider the following code sample:

static void Main(string[] args)
{
    Foo(false, 8);
}

public static void Foo(bool execute, int x)
{
    if (execute)
    {
        Task.Run(() => Console.WriteLine(x));
    }
}

Running this (in release) shows some unexpected allocations happening. Examining the IL shows that that the heap allocation triggered by the closure appears at the very start of the function, rather than inside the condition:

  .method public hidebysig static void 
    Foo(
      bool execute, 
      int32 x
    ) cil managed 
  {
    .maxstack 2
    .locals init (
      [0] class Test.Program/'<>c__DisplayClass1_0' 'CS$<>8__locals0'
    )

    IL_0000: newobj       instance void Test.Program/'<>c__DisplayClass1_0'::.ctor()
    IL_0005: stloc.0      // 'CS$<>8__locals0'
    IL_0006: ldloc.0      // 'CS$<>8__locals0'
    IL_0007: ldarg.1      // x
    IL_0008: stfld        int32 Test.Program/'<>c__DisplayClass1_0'::x

    // [18 13 - 18 25]
    IL_000d: ldarg.0      // execute
    IL_000e: brfalse.s    IL_0022

    // [20 17 - 20 54]
    IL_0010: ldloc.0      // 'CS$<>8__locals0'
    IL_0011: ldftn        instance void Test.Program/'<>c__DisplayClass1_0'::'<Foo>b__0'()
    IL_0017: newobj       instance void [mscorlib]System.Action::.ctor(object, native int)
    IL_001c: call         class [mscorlib]System.Threading.Tasks.Task [mscorlib]System.Threading.Tasks.Task::Run(class [mscorlib]System.Action)
    IL_0021: pop          

    // [22 9 - 22 10]
    IL_0022: ret          

  } // end of method Program::Foo

Am I missing something here, does anyone has an explanation for this strange behavior? Is it possible that Roslyn generates code which allocates for closures regardless of whether we actually execute them?

Answer 1

This behavior is by design.

When your method has a closure, all variables used inside the closure must be part of the closure class (so that the lambda can access their current values).

Had the compiler not allocated the closure immediately, it would have to copy the values from local variables to fields on the closure class when the closure instance is created, wasting time and memory.

That would also make the codegen much riskier and more complicated if multiple lambdas with different reachabilities (or, worse, nested scopes) close over the same variables.

Answer 2

As stated by SLacks, this behavior is by design, since x is a parameter to the function.

However, the allocation can be "moved into" the condition as follows:

public static void Foo(bool execute, int x)
{
    if (execute)
    {
        int localx = x;
        Task.Run(() => Console.WriteLine(localx));
    }
}

In this specific scenario, the transformation is safe because x is not modified within the body of Foo, nor in the lambda. Also, the if statement is not executed within a loop (in which case the transformation might actually increase the number of allocations). The compiler does not make that analysis for you, but you can.