[Gc] GC_base returns non null for a freed pointer

Boehm, Hans 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
costs.

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.

Hans

> -----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 
> pointer) 
> 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.
> 
> 
> Schematically:
> 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.
> 
> Regards,
> 
> Guilhem.
> 
> 
> >Hans
> >
> >On Mon, 16 Aug 2004, Guilhem Lavaux wrote:
> >
> >  
> >
> >>Hi,
> >>
> >>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 ?
> >>
> >>Regards,
> >>
> >>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
> >>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >>
> >>    
> >>
> >
> >  
> >
> 
> _______________________________________________
> 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