[Gc] Using the Boehm-Demers-Weiser GC with a new threading library
hans.boehm at hp.com
Wed May 4 10:28:23 PDT 2005
A couple of additions to Ben's answers:
- Ben's conjecture about pushing the thread structures is correct.
This matters if you put the GC in a dynamic library,
but not have it scan dynamic library data. It also matters
if the client explicitly registers all static roots instead
of having the GC look for them. In the default Linux
configuration, you should be able to safely omit it.
Note that GC_mark_thread_local_free_lists is a different
issue, and must be implemented of you use thread local allocation.
It knows to follow links in otherwise pointer-free objects.
- If your distribution has linux_threads.c, it's a bit old.
In modern distributions, the code resides in pthread_support.c
- For purely cooperative threads implementations, GC_stop_world
tends to be a no-op. In your case it looks as though it might
have to do work for a subset of the threads.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ben Hutchings
> Sent: Wednesday, May 04, 2005 7:13 AM
> To: Stephane Epardaud
> Cc: GC List
> Subject: Re: [Gc] Using the Boehm-Demers-Weiser GC with a new
> threading library
> Stephane Epardaud wrote:
> > Ben Hutchings wrote:
> > > <snip>
> >> If you start from the linux_threads implementation I think you'll
> >> only
> >> need to change GC_push_all_stacks. Use GC_push_all to
> push the active
> >> part of each cooperative thread stack on the mark stack.
> > Hi,
> > Thanks a lot, I'm looking into it right now, but I have two
> > - Why does the linux_thread module need to push the
> GC_threads array on
> > the mark stack in GC_push_thread_structures() ?
> Maybe it's because the GC could be built as a shared library
> and static
> data in shared libraries may not be scanned (this depends on
> configuration and platform; note that this implementation is not just
> used on Linux). Maybe it's not needed at all.
> > - If I use GC_push_all to push the active part of each
> cooperative thread
> > stack on the mark stack as you suggest, will that prevent
> the GC from looking
> > at the non-active part of that cooperative thread stack
> (since the stack in
> > question was allocated with GC_malloc, and I'm sure the
> GC will find a way to
> > that stack from either a root or a global variable) ?
> No; the stack should be allocated using GC_malloc_atomic so that it
> won't automatically be scanned for pointers.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc