Date: Thu, 05 Feb 2004 17:24:02 +0000 From: Nick Barnes <Nick.Barnes@pobox.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Message-ID: <63035.1076001842@thrush.ravenbrook.com> In-Reply-To: <Pine.GSO.4.10.10402050926100.10-100000@pcnet5.pcnet.com> from Daniel Eischen <eischen@vigrid.com> of "Thu, 05 Feb 2004 09:27:37 -0500"
next in thread | previous in thread | raw e-mail | index | archive | help
At 2004-02-05 14:27:37+0000, Daniel Eischen writes: > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > > > > > See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), > > > and pthread_suspend_allnp(3) :-) This is what the native JDK uses for > > > GC. > > > > Way cool. Can I get the context (i.e. registers) of a suspended thread? > > No, you can get the thread attributes which include the stack base > and addr, see pthread_attr_get_np(3). The JDK seems to make do > without getting suspended thread context. Somehow the GC must see the registers of each suspended thread, so that it can preserve any objects to which the registers point. Presumably the thread context is stored in some region which the GC treats as a root (e.g. on the thread stack, identified with pthread_attr_get_np, as you say). A GC which has more information (e.g. the IP, the SP) may be able to use more sophisticated techniques (by using compiler-generated object liveness information, or by excluding dead areas of a stack segment from consideration as roots). The limit of this is a system with close-coupled compiler, thread system, and GC, which can do "precise collection", including modifying the values of registers and stack slots. Nick B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63035.1076001842>