Signal handling rewrite for Linux / i386

Andrew Haley aph@cambridge.redhat.com
Thu Jan 24 05:42:00 GMT 2002


Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >Bryce McKinlay writes:
 > > > 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.

By remapping the guard page with different attributes after it has
been created by the library, I guess.

I don't think it's a good idea.  If we create our own stacks the
memory belongs to us and we can map it any way we like, but I'm not
sure it's legitimate to go around remapping the memory allocated by
linuxthreads.

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

I think that's because some JVMs don't know anything about the
architecture of the target machine: which way the stacks grow, how
many there are, etc.  We're in a fully-compiled native code
environment, so we can interact with system components in different
ways.  This enables us sometimes to use thinner interfaces: as long as
what we're interfacing with is well-defined and stable, that's fine.

The scheme using pthread_getattr_np() would probably work.  However,
it wouldn't be much more portable, more stable, or more efficient.
Also, it might require us to turn off gc while handling a signal --
this is easy for Java VMs to handle but harder for us.

Part of this is a philosophical problem.  Whether you see libjava like
this:

                         +-----------------------------+
                         |                             |
                         |          libjava            |
                         |                             |
                         +-----------------------------+
                         |                             |
                         |            libc             |
                         |                             |
                         +-----------------------------+
                         |                             |
                         |           kernel            |
                         |                             |
                         +-----------------------------+

or like this:

                         +--------------+---------------+
                         |              |               |
                         |   libjava    |      libc     |
                         |              |               |
                         +--------------+---------------+
                         |                              |
                         |            kernel            |
                         |                              |
                         +------------------------------+

We don't always have a choice -- some of the things we do with signals
require us to interface directly with the kernel, because there's no
other reliable way to do it.  That's not necessarily a bad thing,
because in practice kernel ABIs are very well defined and even when
they have to be changed backwards compatiblity is maintained whenever
possible.

Andrew.




More information about the Java mailing list