Garbage collector memory leak "feature"?

[Bill Baxter]

nick.b wrote:
> 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 ?

I posted a bug about AA's causing memory exhaustion (with a test case). 
  If you're talking about a bug where false pointers on the stack cause 
memory exhaustion, I don't think anyone has actually run across such a 
case in practice.

--bb