Why C# Garbage Collection behavior differs for Release and Debug executables? [duplicate]

Question

Let's consider following simple program:

class Program
{
    class TestClass
    {
        ~TestClass()
        {
            Console.WriteLine("~TestClass()");
        }
    }

    static void Main(string[] args)
    {
        WeakReference weakRef;
        {
            var obj = new TestClass();
            weakRef = new WeakReference(obj);
            Console.WriteLine("Leaving the block");
        }

        Console.WriteLine("GC.Collect()");
        GC.Collect();
        System.Threading.Thread.Sleep(1000);
        Console.WriteLine("weakRef.IsAlive == {0}", weakRef.IsAlive);

        Console.WriteLine("Leaving the program");
    }
}

When built in Release mode, it predictably prints:

Leaving the block
GC.Collect()
~TestClass()
weakRef.IsAlive == False
Leaving the program

When Debug version is launched (not under the Debugger, usual launch from Windows Explorer), the output differs:

Leaving the block
GC.Collect()
weakRef.IsAlive == True
Leaving the program
~TestClass()

Running under the debugger for both versions doesn't change the output.

I've discovered this strange difference during debugging of my custom collection that keeps weak references to objects.

Why garbage collector in debug executables does not collect objects that clearly are not referenced?

UPDATE:

Situation differs if object creation is performed in other method:

class Program
{
    class TestClass
    {
        ~TestClass()
        {
            Console.WriteLine("~TestClass()");
        }
    }

    static WeakReference TestFunc()
    {
        var obj = new TestClass();
        WeakReference weakRef = new WeakReference(obj);
        Console.WriteLine("Leaving the block");

        return weakRef;
    }

    static void Main(string[] args)
    {
        var weakRef = TestFunc();

        Console.WriteLine("GC.Collect()");
        GC.Collect();
        System.Threading.Thread.Sleep(1000);
        Console.WriteLine("weakRef.IsAlive == {0}", weakRef.IsAlive);

        Console.WriteLine("Leaving the program");
    }
}

It outputs the same output in Release and Debug versions:

Leaving the block
GC.Collect()
~TestClass()
weakRef.IsAlive == False
Leaving the program

Answer 1

Theodoros Chatzigiannakis has an excellent answer, but I thought I might clarify a couple points.

First off, indeed, the C# compiler generates different code depending on whether optimizations are turned on or off. With optimizations off, locals are generated explicitly in the IL. With optimizations on, some locals can be made "ephemeral"; that is, the compiler can determine that the value of the local can be produced and consumed on the evaluation stack alone, without having to actually reserve a numbered slot for the local variable.

The effect of this on the jitter is that local variables which are generated as numbered slots can be jitted as specific addresses on a stack frame; those variables are considered to be roots of the garbage collector, and they are typically not zeroed out when the C# compiler considers them to have passed out of scope. Therefore they remain roots for the entire activation of the method, and the GC does not collect anything referred to by that root.

Values which merely go onto the evaluation stack are much more likely to be either (1) short-term values that are pushed onto and popped off of the thread's stack, or (2) enregistered, and quickly overwritten. Either way, even if the stack slot or register is a root, the value of the reference will quickly be overwritten, and therefore will no longer be considered reachable by the collector.

Now, an important point is implied by this description of the jitter behaviour: the C# compiler and jitter can work together to lengthen or shorten the lifetime of a local variable at any time at their whim. Moreover, this fact is clearly stated in the C# specification. You absolutely cannot rely on the garbage collector having any particular behaviour whatsoever with respect to the lifetime of a local.

The only exception to this rule -- the rule that you can make no predictions about the lifetime of a local -- is that a GC keepalive will, as the name implies, keep a local alive. The keepalive mechanism was invented for those rare cases where you must keep a local alive for a particular span of time in order to maintain program correctness. This typically only comes into play in unmanaged code interop scenarios.

Again, let me be absolutely clear: the behaviour of the debug and release versions is different, and the conclusion you should reach is NOT "debug version has predictable GC behaviour, release version does not". The conclusion you should reach is "GC behaviour is unspecified; lifetimes of variables may be changed arbitrarily; I cannot rely on any particular GC behaviour under any circumstances". (Except as mentioned before, a keepalive keeps things alive.)