[Gc] Faster to not call GC_free?
jim.marshall at wbemsolutions.com
Mon Jun 4 20:25:59 PDT 2007
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,
#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.
>> -----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
Sr. Staff Engineer
WBEM Solutions, Inc.
More information about the Gc