static field Initialization in debug and release build

Question

I found static field initialization can behave differently. for the following code,

public class Class1
{
  public static void Main()
  {
    Console.WriteLine("Main");
    Test();
    Console.ReadLine();
  }

  public static void Test(){
    Console.WriteLine("Test");
    Singleton.Instance.DoSomething();
  }
}

public class Singleton
{
  private static Singleton sInstance = new Singleton();

  protected Singleton()
  {
    Console.WriteLine("Singleton Constructor");
  }

  public static Singleton Instance
  {
    get
    {
      return sInstance;
    }
  }

  public void DoSomething(){}
}

in the debug build, it will print

Main
Test
Singleton Constructor

while in release build, it will print

Main
Singleton Constructor
Test

I checked the IL code generated of these 2 builds, there are nearly the same.

I wonder how this happens? And if it is a kind of JIT optimization in the release build, what is the motivation?

Answer 1

It completely depends on implementation when static initializers will execute . So the order could be different. But if you provide a static constructor those static initializers will always execute earlier. Hence the output will be in a consistent order.

From MSDN

The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration. If a static constructor (Section 10.11) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.

Add a static constructor in the Singleton class

static Singleton() { }

Answer 2

I repro for the x86 jitter in the release build. This is by design, there is no guaranteed exact moment that the static class constructor runs, the only requirement is that it happens before any other methods in the class run. So the optimizer is permitted to rearrange code if that produces more efficient code. It does, it moves the cctor call all the way back to the Main() method. With the advantage that it now has more opportunities to optimize the remaining code.

In general, you want to avoid writing code in initialization expressions that has observable side-effects.