[Gc] Faster to not call GC_free?

jim marshall jim.marshall at wbemsolutions.com
Sun Jun 3 09:34:25 PDT 2007

Lothar Scholz wrote:
> Hello jim,
> Sunday, June 3, 2007, 12:21:04 AM, you wrote:
> jm> HI,
> jm>  I'm using GC 6.8 in my application, we have designed the application to
> jm> have its memory management be interchangeable (e.g. use GC, dmalloc or
> jm> normal CRT malloc). As such we have designed our application to have our
> jm> own internal allocation routines (mainly macros or inline functions). 
> jm> After doing some reading the indication I get is that I maybe better off
> jm> stubbing out our gc_free calls with no-ops or something like
> jm> #define intFree(vptr) vptr=NULL
> jm> Any thoughts on if this is worth while doing?
> As others said already, GC_free is very usefull for larger objects
> (how large?) but there is something else: false pointer recognition.
This is a good question, what is a "small object"?  Any thoughts on 
that, <5k, <10K, <20K?
> If you have very complex datastructures where everything is pointing
> to each other it is very usefull to replace the GC_free with a
> "memset(ptr,0,size)" and prevent this. This will safe time in the next
> sweep phase, so maybe even the mutex lock of the GC_free might be
> justified.
> Because you have to maintain the free calls anyway for your normal malloc
> i would be really interested in some benchmarks on your system.

Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.

More information about the Gc mailing list