safety of GCJ-generated code

Wed Dec 19 09:32:00 GMT 2001

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.