Garbage collector memory leak "feature"?

[David Brown]

On Wed, Oct 10, 2007 at 03:21:56PM +0000, BCS wrote:
> Reply to Steven,
>
>> to me, gc-that-leaks-memory-by-assuming-random-data-is-a-pointer ==
>> broken gc.  Speed/mem usage is secondary.
>> -Steve
>
> IIRC there is a proof that without some restriction (which are not possible 
> under D) Either a GC will leak, or collect memory early.

I'm not sure I understand why these restrictions aren't possible under D.
They might not be possible with the current implementation, but I didn't
see anything in the language spec that requires inexactness to the GC.

It might not meet some performance or other memory requirements some users
have, but it should be possible to make the GC exact.

This is might actually keep me from using D for one application I'm
writing.  I've managed to carefully place 'delete' statements for the
large, obvious leaks, but the other auto-gc features of D are mostly what
make it a better language for me to use.  As is, my program gradually leaks
more and more memory over time.  It would be cumbersome to have to track
each '~' or array resize and properly free up the old data.

There is a lot about tradeoffs, though.  .NET has an exact GC (or at least
could), but makes interfacing with C code much more cumbersome.

Dave