Special case lifetime analysis

Question

Suppose I have

void foo () {
    Bar bar = new Bar(); // bar is never referred to after this line
    // (1)
    doSomethingWithoutBar();
}

At (1), is the object bar is pointing to eligible for garbage collection? Or does bar have to fall out of scope as well? Does it make a difference if GC.Collect is called by doSomethingWithoutBar?

This is relevant to know if Bar has a (C#) destructor or something funky like that.

Answer 1

Objects can become eligible for garbage collection as soon as it's certain that they will no longer be used. It's entirely possible that bar will be garbage collected before the variable goes out of scope.

Proof:

using System;

class Bar
{
    ~Bar() { Console.WriteLine("Finalized!"); }
}

class Program
{
    static void Main(string[] args)
    {
        Bar bar = new Bar();
        GC.Collect();
        GC.WaitForPendingFinalizers();
        Console.WriteLine("Press any key to exit...");
        Console.ReadLine();
    }
}

Run in Release Mode (because it doesn't get collected in Debug Mode).

Output:

Finalized!
Press any key to exit...

It also works on ideone which uses Mono. The output is the same.

Answer 2

From a quick reading of the spec, it looks like it's implementation specific. It's allowed to garbage collect it, but not required to.

I get this from a note in section 10.9 "Automatic Memory Management" of the ECMA Spec:

[Note: Implementations might choose to analyze code to determine which references to an object can be used in the future. For instance, if a local variable that is in scope is the only existing reference to an object, but that local variable is never referred to in any possible continuation of execution from the current execution point in the procedure, an implementation might (but is not required to) treat the object as no longer in use. end note]

Emphasis mine.

Answer 3

Without defining what version of the CLR you're referring to, it's impossibledifficult to be definitive about the behaviour that you'll see here.

A hypothetical CLR could, in this example, assuming that the following is true:

1. The constructor for Bar does nothing
2. There are no fields that are initialised (i.e. there are no potential side-effects to the objects construction)

Entirely disregard the line Bar bar = new Bar(); and optimise it away as it "does nothing".

As far as my memory serves, in current versions of the CLR bar is eligible for garbage collection the moment after you've constructed it.

Answer 4

Marc answered the question, but here is the solution:

void foo () {
    Bar bar = new Bar(); // bar is never referred to after this line
    // (1)
    doSomethingWithoutBar();

    GC.KeepAlive(bar); // At the point where you no longer need it
}

Answer 5

This can definitely occur. For instance, here is a demonstration that an instance can be finalized while you are still executing its constructor:

class Program
{
    private static int _lifeState;
    private static bool _end;

    private sealed class Schrodinger
    {
        private int _x;

        public Schrodinger()
        {
            //Here I'm using 'this'
            _x = 1;

            //But now I no longer reference 'this'
            _lifeState = 1;

            //Keep busy to provide an opportunity for GC to collect me
            for (int i=0;i<10000; i++)
            {
                var garbage = new char[20000];
            }

            //Did I die before I finished being constructed?
            if (Interlocked.CompareExchange(ref _lifeState, 0, 1) == 2)
            {
                Console.WriteLine("Am I dead or alive?");
                _end = true;
            }
        }

        ~Schrodinger()
        {
            _lifeState = 2;
        }
    }

    static void Main(string[] args)
    {
        //Keep the GC churning away at finalization to demonstrate the case
        Task.Factory.StartNew(() =>
            {
                while (!_end)
                {
                    GC.Collect();
                    GC.WaitForPendingFinalizers();
                }
            });

        //Keep constructing cats until we find the desired case
        int catCount = 0;
        while (!_end)
        {
            catCount++;
            var cat = new Schrodinger();
            while (_lifeState != 2)
            {
                Thread.Yield();
            }
        }
        Console.WriteLine("{0} cats died in the making of this boundary case", catCount);
        Console.ReadKey();
    }
}

In order for this to work, you need to emit a Release build and run it outside Visual Studio (as otherwise the debugger inserts code that prevents the effect.) I've tested this with VS 2010 targetting .NET 4.0 x64.

You can tweak the iterations on the 'keep busy' loop to impact the probability of the Cat winding up finalized before its complete construction.