[Gc] System V contexts and stack marking
hans.boehm at hp.com
Tue Aug 14 14:39:14 PDT 2007
From: Brian Koropoff [mailto:bkoropoff at gmail.com]
Sent: Saturday, August 11, 2007 8:45 PM
To: Lothar Scholz
Cc: Boehm, Hans; gc at napali.hpl.hp.com
Subject: Re: Re: [Gc] System V contexts and stack marking
On 8/11/07, Lothar Scholz <scholz at scriptolutions.com> wrote:
Saturday, August 11, 2007, 6:22:15 AM, you 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
If somebody come up with such a patch, please make the
Fibers/Corroutines additional to any
existing preemptive threading. Because it is often very
good if you can use both of them.
I agree that this would be the best solution. Bruce's idea of
manually marking sleeping fibers sounds
reasonable, but updating GC_stackbottom won't work if there are
any kernel threads which contain
multiple fibers. I propose a very simple API that allows the
client application to warn the GC about
an impending userspace context switch; the GC will either update
GC_stackbottom or (in the
presence of pthreads) update a thread-local variable which
tracks the stack bottom for a particular
kernel thread. This will involve a global lock in case another
kernel thread triggers a collection
before the actual context switch. This means the API would need
to look something like:
void GC_begin_context_switch(char* new_stack_bottom)
The client will need to call GC_begin_context_switch() before
and arrange for GC_end_context_switch() to be called immediately
afterward. It will also need to avoid
triggering the collector between the two calls or risk
deadlock/segfaults. Any thoughts?
-- Brian Koropoff
I'm not a fan of such programming models. But if someone can figure out
how to do this with minimal collector changes, fine.
The collector already has a GC_call_with_alloc_lock routine. The
interface would probably have to specify that the above can only be
called while the allocation lock is held.
Some of the complications I can think of here:
- This would make it the collector's responsibility to mark from active
fibers, and the applications responsibility to mark from inactive ones.
That seems inelegant, and certainly worthy of careful documentation.
- The collectors locks would presumably have to be such that they are
held by threads and not fibers. (Blocking on a lock can't cause a fiber
switch.) I think that's the Windows approach, but it's not universal?
- Itanium has two stack_bottoms per thread. Gc.h defines a
GC_stack_base struct that handles this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc