[Gc] Faster to not call GC_free?

Boehm, Hans hans.boehm at hp.com
Mon Jun 4 17:38:55 PDT 2007


I expect the issue here is that Jim is using debug allocation, which
does store debug information in the object.  There should really be a
GC_debug_size() and GC_SIZE() that adjust for this.  There currently
isn't.  There is s a private DEBUG_BYTES macro that's used to allocate
the object with the extra space.  Thus the definition of GC_debug_size()
should be fairly trivial.  A patch would be welcome.

Having said that, I suspect that the overhead of GC_size, plus a
variable size memset may be starting to approach that of GC_free.  Thus
I'm not sure this is still a win.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Bruce Hoult
> Sent: Monday, June 04, 2007 5:14 PM
> To: jim marshall
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Faster to not call GC_free?
> 
> On 6/5/07, jim marshall <jim.marshall at wbemsolutions.com> wrote:
> > for example is there a set size of data that the GC will 
> add to the ptr?
> > so I can maybe do
> >
> > memset(cptr, 0, ptrSize - GC_MEM_SIZE)
> 
> The GC does not store any data in the objects that it gives 
> you, and doesn't store any GC data next to them either  It 
> gives you the same size or slightly larger object than you 
> asked for.  You can write freely into it.
> 
> Of course if you put a C++ object in there then you have to 
> watch out for VTBL pointers, which could be anywhere (with 
> multiple inheritance).  But you're doing this after you're 
> sure that you're never going to reference this object again, 
> right?  So it's fine.
> 
> The only thing you can't do is clear the object *after* doing a
> GC_FREE() on it.  It does have a link field in it then.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list