[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
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
	
	
	 

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.
 
Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20070814/3f82c506/attachment.htm


More information about the Gc mailing list