RE: safety of GCJ-generated code

[Andrew Haley <aph at cambridge dot redhat dot com>]

Boehm, Hans writes:
 > > From: Andrew Haley [mailto:aph@cambridge.redhat.com]
 > > Boehm, Hans writes:
 > >  > Note that the garbage collector is not aware of 
 > > sigaltstack.  It either
 > >  > needs to be adapted, or we need to make sure that it never 
 > > catches a thread
 > >  > on the alternate stack.  It may suffice to simply mask all 
 > > signals in the
 > >  > SIGSEGV handler.
 > >  > 
 > >  > Another problem with all of this is that on some platforms 
 > > throwing an
 > >  > exception may require a large amount of allocation, e.g. 
 > > to read in debug
 > >  > information for the stack unwinder.  But on X86 that's 
 > > hopefully not an
 > >  > issue.
 > > 
 > > It all gets very complicated, doesn't it?  However, it looks like
 > > sigaltstack is the only way we're going to get this to work.
 > > 
 > Yes.  Though it doesn't sound to me like it's that hard if we just want to
 > deal with the case in which the stack runs into a guard page, but you have
 > plenty of swap space left.  I think it gets much harder if you also want to
 > consider the case in which you ran out of stack space because there's no
 > more more memory or swap space to allocate the next stack page.

We can easily avoid that by creating threads with a rather small stack
size, and only throwing StackOverflowException when we hit a guard
page.  If we really get an out of memory error that's a whole 'nother

 > (On a 64-bit platform, you could probably arrange for the first
 > failure mode to be very unlikely, at which point the second one
 > becomes very interesting.)

For some value of "interesting"  :-)

Andrew.