Date: Fri, 6 Feb 2004 01:32:33 +0200 From: Alexey Zelkin <phantom@freebsd.org> To: Nick Barnes <nb@ravenbrook.com> Cc: freebsd-java@freebsd.org Subject: Re: JDK garbage collector: thread context scanning Message-ID: <20040205233233.GA23899@phantom.cris.net> In-Reply-To: <63663.1076015210@thrush.ravenbrook.com> References: <63663.1076015210@thrush.ravenbrook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040205233233.GA23899>