Eager type init caused by P/Invoke binding dynamics

[crystal-rgb]

Consider static types A with a method void OhGodWhy and B with another method void DoWork and a static constructor (.cctor) .

static class A
{
    static bool IsInit;
    static int LoopCount;

    public static void OhGodWhy()
    {
        if (!IsInit)
            return;

        for (int i = 0; i < LoopCount; i++)
            B.DoWork();
    }
}

static class B
{
    static B()
    {
        // observable side effect
    }

    public static void DoWork() {  /* Actual code */ }
}

(Note that this isn't a minimal repro as I couldn't isolate the behaviour.)
In Release, depending on the shape of the code, the generated asm for OhGodWhy will have the first instruction a type initialisation check for type B followed by a conditional jump to said initialisation and a jump back to the first written line of code. This makes the type B .cctor always run even if we never touch B, by returning early.

Is this intended behaviour? And if so then what's causing it? 👀

I would love to learn more about how the JIT reasons, thank you for your time! 🙂

[huoyaoyuan]

In practice, a type is often considered touched when a method referencing the type get touched.

The timing of static constructor is non-deterministic. It's not suggested to depend on its side effect.

[crystal-rgb]

I’m aware of the non-deterministic nature of static initialization. However, I’m curious about the heuristics or conditions that lead the JIT to choose a particular type as the prime candidate for eager initialization (or even why it did it in the first place).

In my codebase, type B has P/Invoke calls; there’s also a type C which depends on B during its initialization. From what I can tell, the JIT chose to insert the init check for B at the OhGodWhy method prologue, but it seems like C could have been selected as well.

[huoyaoyuan]

I can't get the behavior by testing or reading the JIT source code. JIT triggers type initialization by two ways:

When a field is accessed, the check is inserted to the block of the access:

runtime/src/coreclr/jit/importer.cpp

Lines 9659 to 9671 in 98237c4

	// Check if the class needs explicit initialization.
	if (fieldInfo.fieldFlags & CORINFO_FLG_FIELD_INITCLASS)
	{
	GenTree* helperNode = impInitClass(&resolvedToken);
	if (compDonotInline())
	{
	return;
	}
	if (helperNode != nullptr)
	{
	op1 = gtNewOperNode(GT_COMMA, op1->TypeGet(), helperNode, op1);
	}
	}

Check the type initialization of this at top of the method:

runtime/src/coreclr/jit/morph.cpp

Lines 48 to 56 in 98237c4

	// Insert call to class constructor as the first basic block if
	// we were asked to do so.
	if (info.compCompHnd->initClass(nullptr /* field */, nullptr /* method */,
	impTokenLookupContextHandle /* context */) &
	CORINFO_INITCLASS_USE_HELPER)
	{
	fgNewStmtAtBeg(fgFirstBB, fgInitThisClass());
	madeChanges = true;
	}

[crystal-rgb]

Thank you for the morph/importer bits!
These look like great starting points, I'll dig through the files and hopefully get disasmo running with a checked build of the runtime. The flow graph should reveal some info on the matter.

[AustinWise]

Is class B marked BeforeFieldInit? You can check this with ILSpy or ILDasm. According to the EMCA-335 standard section I.8.9.5, this flag controls the strictness of the timing of the type-initializer:

1. A type can have a type-initializer method, or not.
2. A type can be specified as having a relaxed semantic for its type-initializer method (for convenience below, we call this relaxed semantic BeforeFieldInit).
3. If marked BeforeFieldInit then the type’s initializer method is executed at, or sometime before, first access to any static field defined for that type
4. If not marked BeforeFieldInit then that type’s initializer method is executed at (i.e.,
   is triggered by):
   a. first access to any static field of that type, or
   b. first invocation of any static method of that type, or
   c. first invocation of any instance or virtual method of that type if it is a value type or instance methods on interfaces or
   d. first invocation of any constructor for that type

5 . Execution of any type's initializer method will not trigger automatic execution of any initializer methods defined by its base type, nor of any interfaces that the type implements.

There is also this comment in the JIT explaining that when a type is marked BeforeFieldInit, the call to its type-initializer can be hoisted in a method's prolog:

Thus the JIT's cctor responsibilities require it to check with the EE on every static field access using
initClass and before jitting any method to see if a .cctor check must be placed in the prolog.

    * CORINFO_FLG_BEFOREFIELDINIT indicate the class has beforeFieldInit semantics. The jit does not strictly
        need this information however, it is valuable in optimizing static field fetch helper calls. Helper
        call for classes with BeforeFieldInit semantics can be hoisted before other side effects where
        classes with precise .cctor semantics do not allow this optimization.

You can see in the source JIT source several places where the presence of CORINFO_FLG_BEFOREFIELDINIT affects hoisting decisions.

[crystal-rgb]

Sorry for the late reply.
I checked the generated IL for the B class and it doesn't have a BeforeFieldInit. It is a simple P/Invoke class over a native library with a defined .cctor that handles the native initialisation in it. If I understand correctly, this flag is placed on types that have no explicit .cctor defined.

Would you happen to know in which cases the JIT ignores the precise initialisation semantics?

[huoyaoyuan]

It sounds like related to eager bound of P/Inovke. If the P/Invoke is bound earlier, the .cctor of the type also need to be run earlier.

Would you happen to know in which cases the JIT ignores the precise initialisation semantics?

To be precise - there is not really a precise initialization semantic. It's only guarantee to be earlier than required point, and the implementation detail tries to be as late as possible to make it more predictable.

[crystal-rgb]

So i initially missed reading this line:

It sounds like related to eager bound of P/Invoke. If the P/Invoke is bound earlier, the .cctor of the type also need to be run earlier.

Which is a game changer, with this information I was able to create a minimal repro and realise it has nothing to do with loop hoisting optimisations.
(Therefore the title change from: Is the jit supposed to hoist init type checks this hard?)

The following code has this exact behaviour where it checks if B is init in the prologue before anything in the method runs, which only happens if we use SuppressGCTransition:

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

static class Program
{
    static bool IsInit;
    static int N = 1000;

    [MethodImpl(MethodImplOptions.NoInlining)]
    static unsafe void OhGodWhy()
    {
        if (!IsInit)
            return;

        byte* p = stackalloc byte[64];

        for (int i = 0; i < N; i++)
            B.memset((IntPtr)p, 0x7F, (UIntPtr)64);
    }

    static void Main()
    {
        Console.WriteLine("Call #1 (IsInit=false) - SHOULD NOT run B..cctor");
        OhGodWhy();

        Console.WriteLine("Call #2 (IsInit=true)  - SHOULD run B..cctor");
        IsInit = true;
        OhGodWhy();
    }
}

static class B
{
    static B()
    {
        Console.WriteLine("B..cctor");
    }

    [SuppressGCTransition] //<- this is the culprit.
    [DllImport("msvcrt.dll", EntryPoint = "memset", CallingConvention = CallingConvention.Cdecl)]
    internal static extern IntPtr memset(IntPtr dest, int c, UIntPtr count);
}

Because this surprised me, I looked at the generated ASM around the native call site for both cases:
For the one with suppression it was something simple like: call rax ; B:memset(nint,int,nuint):nint
For the one without the attribute, it looked more like a managed call: call [B:memset(nint,int,nuint):nint] which goes through the precode and from there either to:
- the actual native method address
- precode -> CLRStub[ThePreStub] -> PreStubWorker -> jmp rax (which is the patched point); somewhere along this chain type B is being inited

[huoyaoyuan]

which only happens if we use SuppressGCTransition:

This is the game changer. SuppressGCTransition would change a bunch of things, including how the call is initialized.

Don't use it blindly. Specifically, it's unsuitable for memset which includes loops.

[teo-tsirpanis]

which only happens if we use SuppressGCTransition:

This behavior is documented BTW.

[crystal-rgb]

Yessss memset is kind of a horrible choice for this, I got lost in the sauce trying to understand that type initialisation behaviour, so I picked the first binding I could think of.
That being said the current repro scales badly for bigger buffers, as it potentially forbids the GC from stopping the current thread adding its execution time to the overall GC latency.