[Gc] Faster to not call GC_free?

Hans Boehm Hans.Boehm at hp.com
Sat Jun 2 17:41:47 PDT 2007

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

So, as usual, the short answer is "it depends".


On Sat, 2 Jun 2007, jim marshall wrote:

> HI,
>  I'm using GC 6.8 in my application, we have designed the application to
> have its memory management be interchangeable (e.g. use GC, dmalloc or
> normal CRT malloc). As such we have designed our application to have our
> own internal allocation routines (mainly macros or inline functions).
> After doing some reading the indication I get is that I maybe better off
> stubbing out our gc_free calls with no-ops or something like
> #define intFree(vptr) vptr=NULL
> Any thoughts on if this is worth while doing?
> Thanks
> --
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> 978-947-3607
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list