Apparent problem with GC not collecting on Windows

[Ali Çehreli]

On 11/29/2012 12:06 PM, Michael wrote:
 >> Because you used uint instead of ubyte, array is bigger, memory
 >> exhausts faster.
 > Oh, I see.
 >
 >>> 3. Why it helps?
 >>> GC.free(data.ptr);
 >>
 >> Initial leak happened because for some reason array allocated in
 >> previous iteration was not collected by GC when allocating new one, so
 >> the new one was allocated in another space growing the heap. If you
 >> place GC.free the array gets removed from heap on each iteration and
 >> each new allocation reuses the same memory, heap doesn't grow.
 > If we do this manually it's works, but automatically is broken?
 >

Nothing is "broken." GC.free would have been applied by the GC only if 
there have been no more references to the allocated block of memory.

The fact is, dmd uses a conservative GC. The issue is due to the 
combination of conservative GC, 32-bit address space, and a large chunk 
of memory. When that happens, it is very likely that any other value in 
the system, including an innocent int, has the risk of looking like a 
reference into that memory. For that reason the GC keeps that memory 
block allocated.

The risk of that happening is grossly reduced in a 64-bit address space. 
Similarly, allocating a much smaller buffer helps as well.

Alternatively, we can use a better GC or a runtime that has a better GC.

Ali