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