[Gc] Using multi-threaded GC when not in control of thread creation

Hans Boehm Hans.Boehm at hp.com
Tue Mar 28 21:21:46 PST 2006

As you've probably gathered, we have no great solution for that at the
moment.  In most environments, there is no easy way to enumerate the
threads in a process and get the corresponding stack bounds.

We are working on ways to register threads after the fact.  I'm working on
stabilizing 7.0 on more platforms.  It has an interface to do that.  I
think Bryce McKinley recently posted a patch on the gcj list for older GCs
that does the same thing, but it's more restrictive about platforms.
This may always be a bit tricky if the collector needs to scan entire
stacks, and not just the section younger than the call to the registration
routine.  Gc7 may not support the former on all platforms without
restrictions, since it's not always easy to find the base of thread

On some platforms, you can preload a dynamic library to intercept all thread
creation.  Code has been posted to do that.  But that also turns out to be
less than 100% solid due to an unfortunate interaction with versioned symbols.

On Windows, there are other options using Dllmain to track thread creation.
But that also seems a bit brittle.


On Fri, 24 Mar 2006, Tassos Hadjicocolis wrote:

> Hi,
> We have developed an application that uses GC (statically linked). Our
> application is in the form of a dynamic library and we now want to make
> it thread-safe, as the client applications that will be linking against
> it will now be invoking our API under several threads. The problem is
> that we have no control over thread creation (handled entirely by the
> client application). I understand that this is a problem in the current
> stable GC version, which requires use of GC calls to create threads. Is
> this right and, if so, is there a way around it (e.g. registering
> threads with GC after they are created)?
> I would hate to think we need to give up GC in order to achieve
> thread-safety for our dll.
> Any help would be greatly appreciated.
> Tassos
> _______________________________________________
> 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