[Gc] System V contexts and stack marking

Boehm, Hans 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[2]: [Gc] System V contexts and stack marking
	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


		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

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...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20070814/3f82c506/attachment.htm

More information about the Gc mailing list