Garbage collector memory leak "feature"?

[BCS]

David Brown wrote:
> 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.
> 

The restriction, IIRC, basically limit you to a language like LISP. 
Inline ASM, aliasing of data, unions, direct pointer manipulation, 
passing references to unknown code, etc. prevent you from getting an 
exact GC. (note: I'm working from memory from several different 
conversations over a period of years so don't take this as gospel)

> 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