Garbage collector memory leak "feature"?

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Wed Oct 10 15:21:57 PDT 2007


BCS wrote:
> 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)

Storing type information of all allocations (of heap, stack _and_ static 
variety) would mean that only unions (mixing ptr/refs & other types) and 
void[]s (and static void[N]s) screw up exactness[2]. I think a 
mostly-exact[1] GC could be created, as long as it doesn't move or 
deallocate memory blocks that appear to be referenced by memory whose 
type is indeterminate.
IIRC the spec already states that dereferencing pointers obtained by 
casting from non-pointer data is disallowed, so the other things you 
mention could mostly be "fixed" by disallowing the uses of such 
functionality which break that rule[3].
Other cases can be handled by keeping the current conservative behavior 
(but this should only be done if there's no other reasonable way).

I think that such a GC, even though not exact, would still be a huge 
improvement. I think the cases where conservative behavior is required 
should be pretty easy to keep to a minimum.


[1] Or perhaps a better term is "slightly conservative"?
[2] Probably register contents too; it'll probably be horribly 
space-inefficient to include a mapping of every program location to the 
set of registers containing pointers. (Remember, when a GC pauses all 
other threads so it can collect those other threads could be at any 
instruction in the program)
[3] Or require that objects manipulated in such ways be pinned first.



More information about the Digitalmars-d mailing list