bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext

[Nick Barnes]

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