JDK garbage collector: thread context scanning

[Nick Barnes]

I've been discussing the garbage collection of multi-threaded
applications over on freebsd-threads, and was told there that the
native JDKs have some interesting techniques.  I thought I'd come over
to -java to ask a few questions.  First, some background:

I have several years' experience in writing garbage collectors for
various systems, including runtimes for Standard ML, Common Lisp,
Dylan, and PostScript; and Geodesic's "Great Circle" product.  My
company has an open-source memory management system, the MPS, which
includes various garbage collection techniques
<http://www.ravenbrook.com/project/mps/>.

As I use FreeBSD on my desktop, I tried to port the MPS to FreeBSD a
couple of years ago, and it worked fine except for the multi-threaded
case.  Specifically, the MPS has a pthread management subsystem which
suspends and resumes threads using pthread_kill and a signal handler,
and expects to be able to get the thread context (ucontext, on BSD)
inside the signal handler, in order to scan registers.  This does not
work on FreeBSD 4.x, although apparently it now works on -CURRENT.  I
filed a PR (bin/31661), recently closed by a freebsd-threads
developer.

The ensuing email discussion has been useful to me.  It has educated
me about pthread_suspend_all_np() and related functions, which seem
like great improvement on the pthread_kill/handler/sigsuspend
mechanism which the MPS was using (and which was more-or-less the norm
in garbage collectors a few years ago).

It also included the claim that the 1.4 native JDK does not need to
access the thread context, although the 1.3 JDK did.  I'm intrigued by
this claim, and wonder whether any -java members can enlighten me on
this.  How do you scan the registers without access to the thread's
ucontext?  I presume that you rely on the ucontext's being allocated
somewhere which you will be treating as a (conservative) root?

Thanks in advance for any pointers on this subject,

Nick Barnes
Ravenbrook Limited