[Gc] Faster to not call GC_free?
Hans.Boehm at hp.com
Sun Jun 10 10:56:39 PDT 2007
I should also have mentioned that debug allocation is sometimes
attrociously slow, at least if the collector is configured to store stack
traces in objects. Recent collector versions tend to use the libc
backtrace function for that when available. At least on some X86 linux
systems those don't seem to cache previously computed information, and are
thus MUCH slower than they need to be. I think the correct fix here
belongs into libc.
On Mon, 4 Jun 2007, jim marshall wrote:
> Boehm, Hans wrote:
> > 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.
> You are correct, I probably should have mentioned that - sorry! I'll see
> if I can figure out a GC_debug_size, but I'm am (sadly) not that
> familiar with the GC code.
> > 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.
> I was wondering that myself but figured I would give it a try. Do you
> think setting the ptr to NULL would be enough? For example if I define
> intFree as a macro it would be inline and I could just set it to NULL,
> something like
> #define intFree(vptr) GC_size(vptr)<=1024?vptr=NULL:GC_FREE(vptr)
> At this point I'm just curious, I'll probably just let the code continue
> with it's GC_FREE calls. At least for now as we have a release coming up.
> > 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
> >> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc