Apparent problem with GC not collecting on Windows

[Dmitry Olshansky]

11/30/2012 12:36 AM, 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.
>

I'd just throw in that we have a (almost) precise GC that is used by  at 
least one large project (the VisualD apparently). Though there were some 
problems with it. Anyway I'd expect to see it in upstream by 2.062 at 
least. It should help the cases like this tremendously.

P.S. Either way the manual memory management (and reuse) is the way to 
go with big allocations.

-- 
Dmitry Olshansky