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