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