Re: [Gc] Re: GC v.7.1 DARWIN x86 usage of threads
ivmai at mail.ru
Fri Oct 22 23:24:15 PDT 2010
Wed, 8 Sep 2010 01:25:54 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> 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.
Of course, I didn't mean that.
> I would favor any attempt to make the interfaces more consistent across
So, I've made GC_use_threads_discovery (former GC_use_DllMain), GC_NO_THREADS_DISCOVERY (former GC_NO_DLLMAIN) and GC_DISCOVER_TASK_THREADS (this is a new one) available on both Win32 and Darwin.
> 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?
Yes, DARWIN_DONT_PARSE_STACK now controls only p1 (in GC_stack_range_for).
> 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.
;) That was a Java-like pseudo-code.
> 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.
I've renamed it to GC_use_threads_discovery while preserving the old name (as a macro) for Win32. AICS, at least there is one client - NikoVM (using it to auto-register threads created by Apache).
> 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.
I've fixed this (in the same way as for mach_handler_thread) by adding/using GC_is_mach_marker() (unless GC_NO_THREADS_DISCOVERY).
> > -----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: [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