Garbage collector memory leak "feature"?

[Bill Baxter]

Frits van Bommel wrote:
> Bill Baxter wrote:
>> Vladimir Panteleev wrote:
>>> On Thu, 11 Oct 2007 14:44:04 +0300, Frits van Bommel 
>>> <fvbommel at remwovexcapss.nl> wrote:
> [apparently snipped by Bill]
>>>
>>> The question is, however: is conservative scanning of the stack that 
>>> bad? IMO, it's much less problematic just to tell the user to store 
>>> large amounts of pseudo-random/pointer-like data in the heap or in 
>>> static arrays (data segment).
>>
>> My thinking exactly.  Seems like figuring out how to get classes and 
>> structs with pointers to not scan as all pointers is where the bigger 
>> payoff lies.  Stacks don't usually contain much pointer-like random 
>> data I wouldn't think.
> 
> You say structs should be scanned, but stacks shouldn't. In my 
> experience, structs are quite often stored on the stack...
> 
> (Unless you meant heap/statically-allocated structs instead of structs 
> in general)

Yes, but there just aren't generally that many of them, and they don't 
usually hang around that long.  If you thought they were going to hang 
around a long time you'd have allocated em on the heap.  Thus they're 
not so likely to have so many spurious pointers that you end up with 
memory exhaustion.  Also the workaround is simple, just heap allocate 
any big trouble makers.

And yes, I meant classes and structs on the heap not the stack (and that 
includes structs that are members of a class, which is a pretty common 
case for me.)


--bb