Garbage collector memory leak "feature"?

[BCS]

Sean Kelly wrote:
> David Brown wrote:
> 
>>
>> 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.
> 
> 
> With one stipulation, I believe this could be true of blocks allocated 
> by the GC.  Type information could be supplied by the runtime, etc, to 
> allow exact scanning.  The stipulation being that D users may have a 
> desire or a need to occasionally allocate untyped memory blocks, such as 
> void[].  In these cases, conservative scanning would be necessary.
> 

I was trying to think of a case where you could have untyped data space 
with hard to track pointers. one case came to mind:

file formats. One way to read binary files is to define the format in 
such a way that a whole file can be read into memory and then have "file 
pointers" patched up as "memory pointers". The block that gets read is 
of unknown types. Slight variations on this result in having lost of 
small blocks of memory with data in them where the only way to known the 
type is to walk into it from who only known where. To GC that correctly 
you would need to walk the data tree correctly, and you can bet there 
will be some unions of pointers in there.

> However, that still leaves the stack as an unknown element.  At present, 
> the GC doesn't know anything about what a pointer-sized stack value 
> represents, and I don't see how this could be communicated or 
> determined.  But perhaps this is just a gap in my knowledge of GC theory.
> 

you could even have the stack precisely scanable by treating each stack 
frame as a object (push a function pointer on for every stack frame, 
this function picks out the pointer of the current stack frame) But that 
is just wrong.

> 
> Sean