RE: ObjC configured --with-objc-gc needs external Boehm gc

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Helge Hess [mailto:helge.hess@skyrix.com]
>
> In this context: How does BoehmGC access threading ? Libobjc has it's
> own threading-backend architecture. This might be 
> reused/shared as well
> (in one or the other direction).
> 
The collector supports threads only on some of the most common platforms.
Currently these consist of

- Linuxthreads (most hardware)
- Win32 threads
- Solaris threads (both variants)
- Irix pthreads

Recent versions (more recent than the gcc tree) add support for HP/UX 11,
Windows CE, and Compaq Tru64 (Tru64 is completely untested, AFAIK).

It uses the system provided thread primitives directly.  In many cases it
also uses some flavor of hardware test and set instruction directly, in
order to get better locking performance.

For pthreads (including old-style Solaris threads), the collector needs to
intercept some pthread primitives, since it has to keep its own shadow
thread data structures to hold information about thread stack location, etc.
This is traditionally done by #define'ing functions like pthread_create in
gc.h, and making sure that gets included in files that need these
primitives.  In a GNU environment, it can also be done using the GNU linker
--wrap facility.

It looks to me like this is mostly consistent with libObjC requirements?
The only issue might be the wrapping of pthreads calls made from the libObjC
thread layer?  Do you currently build separate versions of this for the GC
case?

The collectors use of thread primitives tends to be performance critical.
Thus I would rather not move it on top of some higher thread abstraction
layer.

[Tom Tromey wrote:]
> What Hans proposed is making ALL_INTERIOR_POINTERS a runtime option
> and not a compile time option.  I think simply enabling it by default
> would entail a performance hit for Java.  I'd rather not enable it
> until the appropriate change is made.
It sounds like Objective C currently doesn't use ALL_INTERIOR_POINTERS, and
there is some controversy about whether it should?

Assuming this needs to be changed, I agree with Tom.  ALL_INTERIOR_POINTERS
doesn't actually affect the run time of the collector in any obvious way.
It affects mostly the initialization and format of some tables.  The actual
pointer validity checking is done largely by table lookup in either case.
But it does have some other performance impacts related to false pointer
scanning and large object allocation.

(Even if Objective C doesn't need the change, it would potentially be a
useful one, since C clients generally want ALL_INTERIOR_POINTERS.  But that
would lower its priority in my eyes.  I guess the other advantage of making
it runtime configurable is that the Objective C maintainers wouldn't really
have to agree ...)

Hans