safety of GCJ-generated code

Wed Dec 19 09:23:00 GMT 2001

> 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. (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.)
Supposedly C++ operator new throws an exception if you're out of memory, so
ideally much of this SHOULD already work. (I think the standard is worded
so that this isn't really a requirement.) Somehow I doubt this really works
reliably on many platforms, at least if a small allocation caused you to run
out of memory.
Hans