From owner-freebsd-java@FreeBSD.ORG Thu Feb 5 13:07:38 2004 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C78016A4CF for ; Thu, 5 Feb 2004 13:07:38 -0800 (PST) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A169243D54 for ; Thu, 5 Feb 2004 13:07:25 -0800 (PST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) i15L6pWm011083; Thu, 5 Feb 2004 21:06:51 GMT (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id i15L6olb063664; Thu, 5 Feb 2004 21:06:51 GMT (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: freebsd-java@freebsd.org Date: Thu, 05 Feb 2004 21:06:50 +0000 Message-ID: <63663.1076015210@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: mps-staff@ravenbrook.com Subject: JDK garbage collector: thread context scanning X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 21:07:38 -0000 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 . 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