Garbage collector memory leak "feature"?

[Steven Schveighoffer]

"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> 1. Is this just the way all garbage collectors are?  Is there not a way 
>> to solve this problem?
>
> Not all garbage collectors are like this.  Java, for example, uses an 
> exact GC.  The accuracy of a GC is really a combination of the GC design 
> and of the reflection facilities provided by the language.  D's reflection 
> facilities are somewhat limited and will likely never be perfect because 
> it is a systems programming language and does not run in a VM.

OK, I can see where you are coming from.

>
> One slightly weird or confusing thing about D now is that void[] arrays 
> are treated as if they contains pointers.  This is likely a significant 
> source of "leaks."  However, treating void[] arrays as if they contain 
> pointers is reasonable, given the concept that void represents.

Yeah, I'd say if you are relying on void arrays to store your pointers, you 
should be SOL.  If you want to use void[] to contain pointers, you should 
also have to maintain the pointer somewhere else as well to prevent the 
memory from being collected.  Can anyone give an example of where this is 
*necessary* and not just convenient?

If this problem did not exist with void[], would these memory leak problems 
be solved?

>
> The accuracy of garbage collection in D could be further improved by 
> increasing the amount of type information available to the GC.  For 
> example, if the GC knew /where/ in a memory block the pointers were, it 
> could ignore the other parts.  However, this would also increase the 
> memory used by the GC because it would have to store mask info or 
> something comparable for allocated blocks.  It could also slow down 
> collection in well-behaved (ie. lucky) apps because the collection 
> algorithm would be a bit more complicated.

It would be nice if this was up to the developer.  For example, Microsoft 
C++.NET solves this problem by having two types of memory, gc memory and 
'classic' memory.  If you want to use the garbage collector (they call it 
'managed' code), you declare your class with a __gc modifier.

Would it be possible to allow for optimizations for people who are not 
interested in garbage collection, but are interested in speed/mem usage, to 
use some other memory allocation scheme that does not use the garbage 
collector?  Then throw away the assumptions that have caused these leaks to 
occur (e.g. void[] can contain pointers)?

>
> There are also other GC designs that could be used, but those would mostly 
> affect the speed of garbage collection rather than its accuracy.
>

to me, gc-that-leaks-memory-by-assuming-random-data-is-a-pointer == broken 
gc.  Speed/mem usage is secondary.

-Steve