[Gc] Re: Memory leak located!

Hans Boehm Hans.Boehm at hp.com
Mon May 26 18:42:36 PDT 2008



On Mon, 26 May 2008, Martin Wartens wrote:

>> Whether or not it really fixes the allocator problem depends on whether
>> the default allocator calls new directly or allocates large chunks with
>> new and then divides them.  I believe it's still common to do the latter.
>> In that case, this change will probably help, but possibly only in the
>> sense that it hides the underlying bug for longer.  My recommendation
>> would still be to explicitly use a garbage collecting allocator whenever
>> possible.
>
> My implementation (Microsoft VC8) just calls new. But I don't know what the
> standard says about that. What would be the problem with the large chunk thing?
I believe the standard requires that ::new be used, but allows subdividing 
large chunks.  I believe that both the original HP and SGI STL divided 
large chunks by default.  It's a lot faster on toy test programs.  It's 
less clear how it impact the performance of real code.

If the STL uses chunk-based allocation, and ::new allocates collectable 
memory, then objects will be collected only when the entire chunk is no 
longer referenced.  If a statically allocated point p points to a object a
in chunk A, and object b in chunk A points to c in chunk C, chunk C will
also be retained, since the whole chunk A looks like a single object to 
the collector.  For some applications this may be OK, but in general, it's 
not.

Hans

>
> When you forget gc_allocator in a program with mixed gc and non-gc the GC
> cannot see pointers to garbage collected objects in the container. That leads
> to a premature collection.
>
>> Maybe the right solution is to introduce yet another macro, say
>> GC_COLLECTABLE_NEW that controls the behavior of global operator new?
>
> That sounds good and it is only a tiny change.
>
> Greetings,
> Martin
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>


More information about the Gc mailing list