[Gc] System V contexts and stack marking

Boehm, Hans hans.boehm at hp.com
Mon Aug 13 17:39:44 PDT 2007


> -----Original Message-----
> From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On 
> Behalf Of Bruce Hoult
> Sent: Friday, August 10, 2007 5:23 PM
> To: Boehm, Hans
> Cc: Brian Koropoff; gc at napali.hpl.hp.com
> Subject: Re: [Gc] System V contexts and stack marking
> 
> On 8/11/07, Boehm, Hans <hans.boehm at hp.com> wrote:
> > This wasn't really intended to be possible without supporting a new 
> > threads implementation in the collector itself.
> >
> > It may be possible to generate a small collector patch to support 
> > semi-threaded, say GC_CUSTOM_COOPERATIVE_THREADS configurations in 
> > which the collector just assumes that if it's running, 
> nobody else is, 
> > no thread is ever preempted while holding the allocation 
> lock, there 
> > is no point in thread-local allocation, or parallel GC, and 
> the client 
> > is responsible for replacing GC_push_other_roots with a 
> pointer to aan 
> > appropriate thread stack marking routine.
> >
> > The THREADS macro would still need to get set in such an 
> environment, 
> > so theat GC_clear_stack doesn't get confused.  LOCK and 
> UNLOCK could 
> > probably be empty.
> 
> We use GC in our cooperatively-threaded environment.  We 
> simply use GC_push_other_roots on thread stacks other than 
> the current one, and set GC_stackbottom on each thread switch 
> to keep other things happy.
> We don't define THREADS.
> 
That's surprising to me.  You might want to look at the code around
misc.c:300 in the CVS version.  It tries to clear the stack once a
collection cycle, up to the hottest SP value it has seen recently.  If
the collector is invoked from a different stack, it is likely to try to
clear the area between stacks, with bad results.  I remember seeing
failures along those lines.

Perhaps you are always triggering the GC from the main thread?  If not,
it would be usefull to know what that code is actually doing in your
environment.

This does suggest that it might be easier not to set THREADS, but have
that code check another macro like GC_CUSTOM_COOPERATIVE_THREADS as
well.

Hans



More information about the Gc mailing list