Signal handling rewrite for Linux / i386

Bryce McKinlay bryce@waitaki.otago.ac.nz
Wed Jan 23 15:50:00 GMT 2002


Andrew Haley wrote:

>Bryce McKinlay writes:
> > 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?
>

I was assuming that the OS can make better decisions about stack size 
than we can, but you may be right about Java stacks being smaller than 
C/C++ ones.

> > 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.
>

I think you could do all this within the stack allocated by the OS, 
using the information returned pthread_getattr_np(), but I don't have a 
good argument as to why that would be better. I'm just wondering why 
this function was needed in glibc if the JVMs could avoid the issue by 
allocating their own stacks like your patch does.

regards

Bryce.




More information about the Java mailing list