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

Ivan Maidanski ivmai at
Thu Sep 2 13:48:47 PDT 2010

Mon, 30 Aug 2010 17:02:32 -0700 Jim Hourihan <jimhourihan at>:

> 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().
> My patch merely adds a list of threads to exclude from this process. Basically I made a darwin specific version of GC_unregister_my_thread called GC_darwin_exclude_my_mach_thread which adds the calling thread to the exclusion list. Probably a better way to do this would be to have a darwin version of GC_(un)register_thread instead that works with the existing code.

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?

BTW. GC_push_all_stacks contains (for i386 if not DARWIN_DONT_PARSE_STACK) the following:
        /* FIXME: Remove after testing: */
        WARN("This is completely untested and likely will not work\n", 0);
Should we finally remove this line? Do anyone know it is working or not?

>    -Jim
> On Aug 30, 2010, at 3:47 PM, windev92 wrote:
> > thanks Jim and Ivan for your quick response.
> > 
> > I understood in the meantime how to use it, there is no other way than using
> > pthread on DARWIN.
> > gc.h overrides pthread_create, and registers it. We just need to inculde gc.h
> > and this does the trick. My gc client code is portable, has to run on win32 and
> > darwin, that means, on Win32 I ll have to use pthread_create as well for code
> > clarity.
> > 1. Did any of you have tested pthread_create instead of GC_CreateThread on
> > Win32(v.7.1)? Does it work fine?
> > 2. Jim, I m not sure if I have understood you well. Do you mean that if you have
> > a non-libgc-pthread (not including gc.h), stop_the_world will also suspend it?
> > Could you please detail your idea with a use case, with expected behavior
> > against wrong behavior you have noticed?
> > Please also share your patch, and how to use it, is it 7.1 by the way?
> > 
> > Many thanks

More information about the Gc mailing list