[Gc] GC_base returns non null for a freed pointer
hans.boehm at hp.com
Mon Aug 16 14:13:12 PDT 2004
I'd vote for changing the logic :-) .
That code has a race anyway, right? The object p may have been reallocated
for a different purpose in the meantime.
Currently GC_base runs in basically constant time. In order to change
its behavior, it would either have to walk a free list, or GC_free would
have to mark objects with a magic number. (GC_base would still have
to walk the free list if it found the magic number.) Both have significant
This gets more complicated when you switch to thread-local allocation,
which you probably want to do in most cases. At that point GC_base would
presumably have to know about and walk the per-thread free lists. And
it's not clear how you can really avoid races like the one I just mentioned.
I did change the heading comment in gc.h to clarify the semantics:
You can use GC_base() to distinguish between the GC-administered heap
and other parts of the address space; you can't reliably use it
to distinguish between free and allocated objects.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Guilhem Lavaux
> Sent: Monday, August 16, 2004 11:23 AM
> To: Hans Boehm
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] GC_base returns non null for a freed pointer
> Hans Boehm wrote:
> >This is normal. It would be relatively expensive to do something
> >different without having GC_free store a magic number in
> free objects,
> >or the like. GC_free puts the object on a free list, but doesn't
> >otherwise label it.
> >Is this a problem? The current semantics have generally
> been OK for what
> >I've needed.
> It's a problem for a particular construction we have in kaffe
> where we
> don't exactly trace an object, it happens during java/lang/Class
> destruction when we unload JITed code: the code may (or may not) have
> been JITed. In any cases we free some object which represents
> the java
> code. But there may be another object (represented by another
> which represents the trampoline code. If we know (using the GC and so
> GC_base) that this object has already been freed by the previous
> instruction we don't do anything. But if the object is different, we
> free it.
> pointer p;
> pointer p2;
> free p;
> if (p2 is still valid object)
> free p2;
> Actually, the logic can be changed to overcome this
> limitation but this
> feature could be interesting in some other cases.
> >On Mon, 16 Aug 2004, Guilhem Lavaux wrote:
> >>I have merged a kaffe interface to gc6.3 in the kaffe's CVS head and
> >>I've noticed that if I free an object (using GC_free)
> GC_base continues
> >>returning a non-null pointer. Is it the normal behaviour ?
> >>Guilhem Lavaux.
> >>P.S.: I have just subscribed to the mailing list so I
> apologize if the
> >>question has already been asked.
> >>Gc mailing list
> >>Gc at linux.hpl.hp.com
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc