[Gc] Re: GC v.7.1 DARWIN x86 usage of threads

Boehm, Hans hans.boehm at hp.com
Tue Sep 7 18:25:54 PDT 2010

I agree with Ivan's interpretation, though I'm not sure this code has a
common history with the Windows code.  I suspect it was independently
developed, and mostly not by me.

I would favor any attempt to make the interfaces more consistent across

It seems to me that the DARWIN_DONT_PARSE_STACK macro is really controlling
two separate features that should be separated:

1. Is the stack parsed to find the stack base?
2. Are the threads to be stopped found by traversing the GC's thread table
or by asking the Mach kernel to enumerate the threads?

If you separate those, and implement thread registration correctly,
shouldn't that address the issue?  GC_threads should already track the
registered threads, so I don't think we need a new data structure.

Although it's tempting to use STL data structures here, I would avoid it,
just to keep the collector consistently buildable with just a C compiler.

Unifying this with GC_use_DllMain would be great, though that name is clearly
a misnomer on MacOS.  It probably has few enough clients that we could get
away with renaming it.

The fact that we're currently registering parallel markers just seems to be
a bug.  That may explain that PARALLEL_MARK is not enabled by configure.ac
for Darwin.


> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Monday, September 06, 2010 11:24 PM
> To: gc at linux.hpl.hp.com
> Cc: Boehm, Hans
> Subject: Re[3]: [Gc] Re: GC v.7.1 DARWIN x86 usage of threads
> Hi!
> I'm trying to understand the darwin-specific part to implement
> register_my_thread for darwin (and prevent stopping of marker threads).
> Looking into GC_push_all_stacks, its implementation looks to me similar
> to Win32 DLL-based approach - we use task_threads() (in case of
> !DARWIN_DONT_PARSE_STACK) instead of iterating over GC_pthread just to
> scan all thread even if it wasn't registered (neither explicitly nor
> pthread_create wasn't intercepted).
> If I'm right, the solution comes from Win32 - deprecate old behavior (I
> mean scanning all threads) and scan only threads that are registered,
> but leave the possibility to use the old behavior (i.e. implement
> GC_use_DllMain() for darwin which turns on the old one but disables
> parallel markers).
> Hans - any comments?
> And the 2nd question: how to implement suspend/resume for only the
> registered threads (unless switched to old behavior) - use something
> like HashSet<task_t>?
> Fri, 03 Sep 2010 00:48:47 +0400 Ivan Maidanski <ivmai at mail.ru>:
> >
> > Mon, 30 Aug 2010 17:02:32 -0700 Jim Hourihan <jimhourihan at gmail.com>:
> >
> > >
> > > The patch is against 7.2alpha, I'll get the 7.1 code and create it
> against that when I get a chance. The main thing is that this function
> GC_stop_world() in darwin_stop_world.c is stopping *all* task threads
> (in mach parlance) and scanning their stacks.
> >
> > To be precise, if DARWIN_DONT_PARSE_STACK then only registered thread
> stacks are scanned.
> >
> > And, it seems to erroneously stop the parallel marker threads too.
> >
> > > GC_stop_world for darwin calls the mach system call task_threads
> followed by GC_suspend_thread_list which loops over the thread list
> eventually calling  the mach API thread_suspend on each except the
> invoking thread. It doesn't use any other information (i.e. registered
> threads list). I found this out because it was stopping my HAL audio
> thread which was causing popping.
> > >
> > > So basically, AFAIK, on darwin the pthreads interface is moot. The
> code actually uses the more low-level mach interface which makes the
> code very simple and easy to follow, but ignores the thread
> registration part of the gc API. So you don't need to call
> GC_register_my_thread and doing so will have no effect. Likewise with
> GC_unregister_my_thread.
> > >
> > > You see all of this pretty easily if you put a break point in
> GC_stop_world().
> > >
> > > ...
> >
> > AICS, to stop and scan only registered threads on Darwin, we need to
> maintain HashSet<task_t> (in GC_register/unregister_my_thread) and test
> this set in threads start/stop/scan. Do I miss something?
> >...

More information about the Gc mailing list