Signal handling rewrite for Linux / i386

Andrew Haley aph@cambridge.redhat.com
Wed Jan 23 02:09:00 GMT 2002


Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >> Don't we lose something by circumventing the kernel's
 > > > variable-size/floating stack feature?
 > >
 > >I don't think so.  If we're going to detect stack overflow, and the
 > >JLS says we must, we need to have some fixed limit.  Inevitably any
 > >such limit will be rather arbitrary.
 > >
 > 
 > Have you considered the pthread_getattr_np()? This was apparantly added 
 > specifically to support the JVMs and gives you the stack size and 
 > location for a running thread including the size of the guard pages. 

 > I guess we'd still need the sigaltstack stuff, but should be able
 > to avoid mapping our own stack explicitly?

I don't think so, but even if we could, why would we want to?

 > It should also be possible to just figure out if the fault address
 > was within the guard pages that were set by linuxthreads?

I don't think it would help.  The guard page I use has special
properties, and the whole stack must be mapped in order for the gc to
be able safely to work.

The idea that makes all this work is to make the guard page read-only:
this means that the gc can scan it.  The position of the altstack
means that it's within the allocated stack for the thread, so that
it's possible easily to convert from a stack pointer value to a thread
id, even while we're on the altstack.

All this makes it possible to just call throw() while on the altstack,
have the unwinder work normally, and we don't need to interact with
the gc or the threads package.

Andrew.










More information about the Java mailing list