[Gc] System V contexts and stack marking

Brian Koropoff bkoropoff at gmail.com
Sat Aug 11 20:44:44 PDT 2007


On 8/11/07, Lothar Scholz <scholz at scriptolutions.com> wrote:
>
>  Hello Hans,
>
>
> 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)
void GC_end_context_switch(void)

The client will need to call GC_begin_context_switch() before doing
setcontext()/swapcontext()/what-have-you,
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20070811/e31ab550/attachment.htm


More information about the Gc mailing list