[Gc] Re: GC needs to be invoked manually

Boehm, Hans hans.boehm at hp.com
Wed Aug 31 15:50:24 PDT 2005

> -----Original Message-----
> From:  Martin Wartens
> > The heuristics used by the collector are always debatable.  But in 
> > this case I think it's actually dead on.
> I think this case is not different from the other: In both 
> cases there is a 
> large amount of uncollectable memory that is only destroyed 
> by finalizing a 
> collectable object. 
>From the collector's perspective, you're correct.  And there lies
the problem.

If we assume that the collector's primary goal is to minimize the
time it takes to recover a byte of memory, and that running
finalizers is only a way to take advantage of information the
GC has anyway, then putting off GC in the first case
is perfectly reasonable, since running finalizers/destructors
doesn't cause any memory to be recovered.

In the second case, since the destructors do deallocate memory,
things are different.  But the GC has no way to know that.
> > It turns out this is already fixed in gc7.0alpha5, which 
> uses a more 
> > robust heuristic.
> What does it do?
The major difference is that it compares the amount of memory
allocated since the last GC to the amount of live memory at the last GC.

GC6.5 looks at current heap size instead of live memory at last GC,
since it doesn't track live memory for performance reasons (largely
overcome by other 7.0 changes).  It arguably should look at heap size
at the last GC, but that would be a performance regression for some
apps, and it wouldn't address some other issues which are probably
more important for most real apps.
> > In general, this code is well outside the comfort zone for tracing 
> > collectors.  You really don't want a very large fraction of the 
> > objects to be finalizable (e.g. by inheriting from gc_cleanup), or 
> > reachable from finalizable objects.  Making all the objects 
> > collectable works MUCH better.
> I agree that traceable_allocator/MALLOC_UNCOLLECTABLE is 
> useful only in rare 
> situations. What is so bad about gc_cleanup? Does 
> finalization slow down the 
> collection?
Yes.  Substantially.  Finalizable objects are tracked in a separate
data structure.  Thus gc_cleanup objects require a second allocation,
and a bunch of additional GC work.  (In the case of this collector,
that extra work isn't parallelized, so it's particularly painful
with parallel marking enabled.)

There is some empirical discussion of this, in a Java context,
on slides 5 and 6 of my JavaOne talk:


(The Java spec give you the impression that every object is finalized.
That's not how implementations work.)

This implementation style is driven in part by the observation that
finalization is usually rare.  But even if you tried to optimize that
path, I think the cost would still be substantial.  Just touching the
object to look up the virtual destructor will normally cost you
a cache miss.


More information about the Gc mailing list