[Gc] Faster to not call GC_free?

Bruce Hoult bruce at hoult.org
Sat Jun 2 18:23:48 PDT 2007


On 6/3/07, Hans Boehm <Hans.Boehm at hp.com> wrote:
> I haven't measured this recently.  My guess, based on some older
> measurements, is that for small object with threads, stubbing out the
> GC_free may be s substantial win.  GC_free always acquires a lock,
> which often dominates everything else.  Even in the single-threaded case,
> the collector is generally significantly faster at reclaiming small
> objects than GC_free.
>
> With very large objects, the opposite is generally true, often by
> a large margin.  Calling GC_free on these effectively pushes back the
> next garbage collection significantly, and it's a relatively cheap
> operation.
>
> So, as usual, the short answer is "it depends".

It also depends on how much larger you're prepared to let the heap be
than the amount of live data (controlled by GC_DIVISOR).  WIth a tight
heap there will be lots of GCs and very little will be reclaimed each
time and GC_free helps a lot.  With a loose heap there will not be so
many GCs and the percentage of the heap that is reclaimed cheaply will
be large.

Basically, the cost of GC_free vs the cost of the GC itself
discovering that that particular object is not used are not very
different.  The difference comes in GC_free putting off the GC having
to scan all the live data -- possibly forever if you use GC_free
consistently in your inner loop.

But be very careful!  Be very very sure that there is only one pointer
to that object -- that you really do own it.  Using GC_free opens you
up to almost all the same bugs that you can have using traditional
malloc/free.  Double deletes.  Using an object after it has been
deleted, possibly overwriting a new object (the object you GC_free
will be the very first memory of that size to be allocated next).
Even if you don't corrupt that new object, the existance of another
pointer to that memory when you GC_free it can cause the new object to
be wrongly retained, along with anythign it points to.  If that memory
hasn't been reused yet at the next garbage collect then the existance
of another pointer to that memory will cause the GC to mark memory
blocks that are in the free list for that size memory block, wasting
time and possibly scanning and retaining more things that should not
be.


More information about the Gc mailing list