[Gc] Re: Memory leak located!
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
> 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
> 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.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc