Garbage collector memory leak "feature"?

[nick.b]

David Brown wrote:
> On Wed, Oct 10, 2007 at 05:47:12PM +0200, 0ffh wrote:
> 
>>> You can have limited void*, if you retain the types in the blocks 
>>> that are
>>> allocated.  What you can't do is use casts to view things of one type 
>>> as a
>>> different type.
>>
>> If you always have to retain the types, what would be the use of void*s?
>> The point about them is that a void* may point to anything, pointers
>> included, which is what makes them painful for the gc.
>> Btw unions of pointer- and non-pointer types cause the same problem,
>> so it's not even all about void* (probably most, though).
> 
> If the type is retained in the managed GC-allocated blocks, the GC can
> determine if a void* points to a GC-allocated block or not (it already
> decides this).  It can then look at the header to see if the block contains
> pointers.
> 
> In fact, it already does this.  It's just that the determination of whether
> the block contains pointers is a binary flag covering the whole block.
> Approaches I've seen are to reorder GC-managed blocks so that the pointers
> were always at the beginning, and have in the header a count of how many
> pointers are in the blocks.
> 
> The other important part is when you walk the stack (and static data) for
> pointers, you need to be able to tell what is and isn't a pointer.  This
> requires the compiler to sufficiently annotate it's stack frames.  The D
> spec indicates that Walter at least thought about this, whether the current
> compiler does this or not.
> 
> David

There have been a lot of excellent posts on this issue, and suggestions 
on how this issue could be fixed/corrected.  I have one question:  Has 
anyone posted this as a bug ?

Nick