static constructors and BeforeFieldInit?

Question

If a type has no static constructor, field initializers will execute just prior to the type being used— or anytime earlier at the whim of the runtime

Why this code :

void Main()
{ 
  "-------start-------".Dump();
   Test.EchoAndReturn("Hello");
  "-------end-------".Dump();

}

 class Test
{
    public static string x = EchoAndReturn ("a");
    public static string y = EchoAndReturn ("b");
    public static string EchoAndReturn (string s)
    {
        Console.WriteLine (s);
        return s;
    }
}

yields :

-------start-------
a
b
Hello
-------end-------

while this code :

void Main()
{ 
  "-------start-------".Dump();
   var test=Test.x;
  "-------end-------".Dump();

}

yields

a
b
-------start-------
-------end-------

The order of a and b is understood. but why dealing with static method is different than static field.

I mean why the start and end lines are in different locations with static methods vs static fields ? I mean - in both situation he's got to initialize those fields...so why ?

( I know I can add static ctor which make it to be the same - but Im asking about this particular situation. )

(p.s. Dump() is just like console.write)

Answer 1

The behavior of the release JIT is (from 4.0 IIRC) not to run the static initializer unless the method you are calling touches static fields. This can mean the static fields are not initialized. If I run your first code in release outside of the debugger, I get:

-------start-------
Hello
-------end-------

If I run it with the debugger attached (release), or in a debug build (with or without debugger attached), I get:

-------start-------
a
b
Hello
-------end-------

So far so interesting. For why you get:

a
b
-------start-------
-------end-------

it looks like the per-method JIT is essentially taking responsibility for running the static constructor in this scenario. You can see this by adding:

if(NeverTrue()) { // method that returns false
        "-------start-------".Dump();
        var test = Test.x;
        "-------end-------".Dump();
}

which will print (even in release without the debugger)

a
b

so the possibility of accessing fields is key. If we change Test.x to be a call to a method that doesn't access fields (and remove the NeverTrue() thing), then we get no output whatsoever.

So: in some versions of the CLI, the execution of static initializers may be deferred to the JIT-step of methods that contain mentions to any field (it doesn't check whether that field has an initializer).

We can even create instances of objects without running the static initializer, as long as we don't touch static fields:

 public Test()
 {
     a = "";
 }
 string a;

with:

"-------start-------".Dump();
new Test();
"-------end-------".Dump();

prints just (release, no debugger):

-------start-------
-------end-------

HOWEVER! We should not build anything that depends on this timing:

• it changes between .NET version
• it may well change between platform (x86, x64, CF, SL, .NETCore, etc)
• it can change depending on whether the debugger is attached and whether it is a debug/release build

Answer 2

This is with .NET 4.0

If a type has no static constructor but static fields with initialization, the compiler creates a type constructor and puts the initialization inside it.

class Test
    {
        public static string x = EchoAndReturn("a");
        public static string y = EchoAndReturn("b");
        public static string EchoAndReturn(string s)
        {
            Console.WriteLine(s);
            return s;
        }
    }

Results in the following IL (Just the cctor part)

.method private hidebysig specialname rtspecialname static 
        void  .cctor() cil managed
{
  // Code size       31 (0x1f)
  .maxstack  8
  IL_0000:  ldstr      "a"
  IL_0005:  call       string ConsoleApplication1.Test::EchoAndReturn(string)
  IL_000a:  stsfld     string ConsoleApplication1.Test::x
  IL_000f:  ldstr      "b"
  IL_0014:  call       string ConsoleApplication1.Test::EchoAndReturn(string)
  IL_0019:  stsfld     string ConsoleApplication1.Test::y
  IL_001e:  ret
} // end of method Test::.cctor

Also, according to CLR via C#, the JIT compiler checks each method beforehand, what types have a static constructor. If the static constructor has not been called, the JIT compiler calls it.

That would explain the difference between the two code fragments.

When the just-in-time (JIT) compiler is compiling a method,

it sees what types are referenced in the code .If any of the types define a type constructor, the JIT compiler checks if the type’s type constructor has already been executed for this AppDomain .If the constructor has never executed, the JIT compiler emits a call to the type constructor into the native code that the JIT compiler is emitting .

@Comment

If you move one field initializer into a user-defined type constructor, the compiler will move the other field you initialize on the class level into the type constructor as well.

static Test()
{
  y = EchoAndReturn("b");
}

Results in the same IL as above. So there basically is no difference between your own type constructor and the one generated by the compiler (There can only be one anyway).

Answer 3

The time when static constuctor will be called is not guaranted, so for the programm it is like Undefined Behavior in C++. Nobody should rely on the sequence of static constructor calls. For example if you compile the programm under release you will see that static counstructor called in the same time in both cases.