[Gc] System V contexts and stack marking

Boehm, Hans hans.boehm at hp.com
Fri Aug 10 16:22:15 PDT 2007

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.
If this works,  and results in a small patch, I think it would be fine
to add that support to the standard collector.
This question has come up before in connection with GNU Pth, but I don't
think anyone has ever posted a patch.


	From: gc-bounces at napali.hpl.hp.com
[mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Brian Koropoff
	Sent: Thursday, August 09, 2007 9:13 PM
	To: gc at napali.hpl.hp.com
	Subject: [Gc] System V contexts and stack marking
	    I'm developing an interpreted language runtime that snarfs
the Boehm GC to provide automatic memory management.  My language uses a
userspace threading model based on System V contexts.  I encountered a
major issue with this architecture: if the collector runs in a fiber, it
will attempt to mark between the cold end of the main stack and the hot
end of the fiber stack, hitting an unmapped page in the process and
	    A quick workaround was to wrap setcontext() and
swapcontext() to update GC_stackbottom.  However, this will cause the
main stack to no longer be marked.  I'm wondering if there is a
reasonable solution to this problem that uses only the public APIs.  I
can think of several ways to approach the issue by modifying the
collector, but I'd rather avoid having my language depend on a custom
	    Any suggestions would be appreciated.
	-- Brian Koropoff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20070810/e8ff10e5/attachment.htm

More information about the Gc mailing list