[Gc] gc-7.0 abi incompatible?

Boehm, Hans hans.boehm at hp.com
Wed Jul 25 17:21:53 PDT 2007

That's a variant of the problem that was pointed out previously.  The
issue is that thread-local allocation has become the default and is now
used implicitly with GC_malloc.  But thread-local allocation required
explicit initialization, since the initialization check is more
expensive there.

(There is now a consistent story for initialization:  Call GC_INIT()
from the main object on all platforms before making any GC calls.  It
usually calls GC_init.  If you somehow follow that rule, you won't have
problems.  If you don't, you may unavoidably have problems on platforms
on which only the main executable can find the main data segment, though
you may get away with it if you don't trigger a GC before the GC_INIT
call.  But there are a lot of platforms on which you could get away
without doing this if thread-local allocation performed an
initialization check.)

I'm inclined to put in the check, at least for GC_malloc() and
GC_malloc_atomic(), since this is causing too many problems,
particularly for C++ code that calls GC_MALLOC before main and GC_INIT.

An alternative might be to have gc.h invoke a constructor that calls
GC_INIT.  But I don't think that's 100% solution.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Rex Dieter
> Sent: Tuesday, July 24, 2007 2:34 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] gc-7.0 abi incompatible?
> Upgrading to gc-7.0 (from 6.8) in fedora has revealed a 
> possible abi-incompatibility, see https://bugzilla.redhat.com/248700
> comment?
> -- Rex
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list