[Gc] Faster to not call GC_free?
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.
> -----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
More information about the Gc