JDK garbage collector: thread context scanning

[Alexey Zelkin]

hi,

On Thu, Feb 05, 2004 at 09:06:50PM +0000, Nick Barnes wrote:
> 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

Unfortunately they have mixed issues a bit.  Back in JDK 1.4.0 days
we have had to have information about current stack pointer (esp), and
it was a big problem since there was not way to fetch thread's ucontext.
I tried to work around this issue with direct access to jb (jump buffer)
in same way as gdb(1) does, but some related issues (I don't remember
exactly) did not allow to make this schema work.  Since JDK 1.4.1 we got
correctly working fallbacks, so I was not required to do a black magic
anymore.  If you're interesting about way how JDK (in Solaris case)
get ucontext_t -- they do it in same way as you described -- with
pthread_kill()->sighandler() schema.

According to mentioned above 'access to the thread context' -- it is
also different issue.  JDK needed to know about internal libc_r data
(and this data was not legally exported), so we had to directly use
libc_r's private includes in order to access blackboxed data.  Lately
I have implemented pthread_attr_get_np() function which exported
all required information on application level and we stoped to use
private libc_r structures in JDK 1.4.x

> ucontext?  I presume that you rely on the ucontext's being allocated
> somewhere which you will be treating as a (conservative) root?

As I described above, we don't.  IIRC there's only way to get correct
ucontext_t is to ask kernel for it (via issuing of the signal).  Actually
problem you described in PR mentioned was fixed after required support
was added into the kernel (as part of libpthread development), but
does not rely on threading library you use.  Another story that it's
not possible to get thread's ucontext in libc_r because kernel does
not know anything about libc_r's threads, but that really another story.

Sorry for not saying anything helpful for you :(