views:

102

answers:

1

I've come across some curious behavior with regard to garbage collection in .Net.

The following program will throw an OutOfMemoryException very quickly (after less than a second on a 32-bit, 2GB machine). The Foo finalizer is never called.

class Foo
{
    Guid guid = Guid.NewGuid();
    byte[] buffer = new byte[1000000];

    static Random rand = new Random();
    public Foo()
    {
        // Uncomment the following line and the program will run forever.
        // rand.NextBytes(buffer);
    }

    ~Foo()
    {
        // This finalizer is never called unless the rand.NextBytes
        // line in the constructor is uncommented.
    }

    static public void Main(string args[])
    {
        for (; ; )
        {
            new Foo();
        }
    }
}

If the rand.nextBytes line is uncommented, it will run ad infinitum, and the Foo finalizer is regularly invoked. Why is that?

My best guess is that in the former case, either the CLR or the Windows VMM is lazy about allocating physical memory. The buffer never gets written to, so the physical memory is never used. When the address space runs out, the system crashes. In the latter case, the system runs out of physical memory before it runs out of address space, the GC is triggered and the objects are collected.

However, here's the part I don't get. Assuming my theory is correct, why doesn't the GC trigger when the address space runs low? If my theory is incorrect, then what's the real explanation?

+1  A: 

The code runs at a stable 18MB on my machine, with or without that line (XP SP3 x86, .Net 3.5 SP1, dual core).

Likely what is happening on your machine is that when the line is commented, the program spends most of its time allocating, and manages to allocate too much memory before the garbage collector thread has a chance to deallocate it. When you uncomment that line, the program spends much less time allocating, and thus can't allocate too much before the GC thread runs.

Try replacing the commented line with Thread.Sleep(0); if it doesn't crash, I'm probably correct.


Just as a side note, you shouldn't ever rely on the finalizer - it is not guaranteed to be called immediately when the object is GC'ed, or even at all. Instead, in real code implement the IDisposable interface, and use a finalizer only if it is extremely important that Dispose() be called, even if the programmer forgot it (eg. releasing shared network/file resources, etc.)

BlueRaja - Danny Pflughoeft
I'm not certain you have the right answer, but you put me on an interesting track. I shut down two Virtual PCs I was running (both with 512MB) and I get your behavior. When I loaded the VPCs back up, I got the original crashing behavior.
Kennet Belenky
There are also some interesting functions in the `GC` class to check out, but again, in real code these should never be used.
BlueRaja - Danny Pflughoeft
With the VPCs running, and the Thread.Sleep(0) in place, the program runs forever. Now the question shifts... Why doesn't the GC automatically get triggered on allocation failure?
Kennet Belenky
@Kennet: The GC requires a lot of memory to do its job too. The allocation failure (which comes from the OS) happens when there is *no* memory left to give, even to the GC.
BlueRaja - Danny Pflughoeft