Does the .NET garbage collector perform predictive

问题:

OK, I realize that question might seem weird, but I just noticed something that really puzzled me... Have a look at this code :

static void TestGC()
{
        object o1 = new Object();
        object o2 = new Object();
        WeakReference w1 = new WeakReference(o1);
        WeakReference w2 = new WeakReference(o2);

        GC.Collect();

        Console.WriteLine("o1 is alive: {0}", w1.IsAlive);
        Console.WriteLine("o2 is alive: {0}", w2.IsAlive);
}

Since o1 and o2 are still in scope when the garbage collection occurs, I would have expected the following output:

o1 is alive: True
o2 is alive: True

But instead, here's what I got:

o1 is alive: False
o2 is alive: False

NOTE : this occurs only when the code is compiled in Release mode and run outside the debugger

My guess is that the GC detects that o1 and o2 won't be used again before they go out of scope, and collects them early. To validate this hypothesis, I added the following line at the end of the TestGC method :

string s = o2.ToString();

And I got the following output :

o1 is alive: False
o2 is alive: True

So in that case, o2 isn't collected.

Could someone shed some light on what's going on ? Is this related to JIT optimizations ? What's happening exactly ?

回答1:

The Garbage Collector relies on information compiled into your assembly provided by the JIT compiler that tells it what code address ranges various variables and "things" are still in use over.

As such, in your code, since you no longer use the object variables GC is free to collect them. WeakReference will not prevent this, in fact, this is the whole point of a WR, to allow you to keep a reference to an object, while not preventing it from being collected.

The case about WeakReference objects is nicely summed up in the one-line description on MSDN:

Represents a weak reference, which references an object while still allowing that object to be reclaimed by garbage collection.

The WeakReference objects are not garbage collected, so you can safely use those, but the objects they refer to had only the WR reference left, and thus were free to collect.

When executing code through the debugger, variables are artificially extended in scope to last until their scope ends, typically the end of the block they're declared in (like methods), so that you can inspect them at a breakpoint.

There's some subtle things to discover with this. Consider the following code:

using System;

namespace ConsoleApplication20
{
    public class Test
    {
        public int Value;

        ~Test()
        {
            Console.Out.WriteLine("Test collected");
        }

        public void Execute()
        {
            Console.Out.WriteLine("The value of Value: " + Value);

            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();

            Console.Out.WriteLine("Leaving Test.Execute");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Test t = new Test { Value = 15 };
            t.Execute();
        }
    }
}

In Release-mode, executed without a debugger attached, here's the output:

The value of Value: 15
Test collected
Leaving Test.Execute

The reason for this is that even though you're still executing inside a method associated with the Test object, at the point of asking GC to do it's thing, there is no need for any instance references to Test (no reference to this or Value), and no calls to any instance-method left to perform, so the object is safe to collect.

This can have some nasty side-effects if you're not aware of it.

Consider the following class:

public class ClassThatHoldsUnmanagedResource : IDisposable
{
    private IntPtr _HandleToSomethingUnmanaged;

    public ClassThatHoldsUnmanagedResource()
    {
        _HandleToSomethingUnmanaged = (... open file, whatever);
    }

    ~ClassThatHoldsUnmanagedResource()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        (release unmanaged resource here);
        ... rest of dispose
    }

    public void Test()
    {
        IntPtr local = _HandleToSomethingUnmanaged;

        // DANGER!

        ... access resource through local here
    }

At this point, what if Test doesn't use any instance-data after grabbing a copy of the unmanaged handle? What if GC now runs at the point where I wrote "DANGER"? Do you see where this is going? When GC runs, it will execute the finalizer, which will yank the access to the unmanaged resource out from under Test, which is still executing.

Unmanaged resources, typically accessed through an IntPtr or similar, is opaque to the garbage collector, and it does not consider these when judging the life of an object.

In other words, that we keep a reference to the handle in a local variable is meaningless to GC, it only notices that there are no instance-references left, and thus considers the object safe to collect.

This if course assumes that there is no outside reference to the object that is still considered "alive". For instance, if the above class was used from a method like this:

public void DoSomething()
{
    ClassThatHoldsUnmanagedResource = new ClassThatHoldsUnmanagedResource();
    ClassThatHoldsUnmanagedResource.Test();
}

Then you have the exact same problem.

(of course, you probably shouldn't be using it like this, since it implements IDisposable, you should be using a using-block or calling Dispose manually.)

The correct way to write the above method is to enforce that GC won't collect our object while we still need it:

public void Test()
{
    IntPtr local = _HandleToSomethingUnmanaged;

    ... access resource through local here

    GC.KeepAlive(this); // won't be collected before this has executed
}

回答2:

The garbage collector gets lifetime hints from the JIT compiler. It thus knows that at the GC.Collect() call there are no more possible references to the local variables and that they therefore can be collected. Review GC.KeepAlive()

When a debugger is attached, JIT optimization is disabled and the lifetime hint gets extended to the end of the method. Makes debugging a lot simpler.

I wrote a much more detailed answer about this, you'll find it here.

回答3:

I am not an C# expert but I would say that this is because in production your code is optimize in

static void TestGC()
{
        WeakReference w1 = new WeakReference(new Object());
        WeakReference w2 = new WeakReference(new Object());

        GC.Collect();

        Console.WriteLine("o1 is alive: {0}", w1.IsAlive);
        Console.WriteLine("o2 is alive: {0}", w2.IsAlive);
}

No more o1, o2 binding remain.

EDIT: This is a Compiler optimization named constant folding. Which can be done with or without a JIT.

If you have a way to disable the JIT but kept the release optimization you're gonna have the same behavior.

People should pay attention to the note:

NOTE : this occurs only when the code is compiled in Release mode and run outside the debugger

this is the key.

PS: I am also assuming that your understand what WeakReference mean.

回答4:

Could someone shed some light on what's going on?

Your mental model of how the virtual machine garbage collects resources is unrealistically simple. In particular, your assumption that variables and scope are somehow relevant to garbage collection is wrong.

Is this related to JIT optimizations?

Yes.

What's happening exactly?

The JIT didn't bother keeping references around unnecessarily so the tracing collector didn't find references when it kicked it so it collected the objects.

Note that other answers have stated that the JIT conveyed this information to the GC when the truth is actually that the JIT did not convey those references to the GC because there would be no point in doing so.