[Gc] Can sigaltstack be used in a GC registered thread?

[Andrew Haley]

On 05/21/2012 04:27 PM, Boehm, Hans wrote:

> The core issue here is that stack overflow signals are essentially
> asynchronous.  As far as the programmer is concerned, they can occur
> anywhere.  Worse yet, they may occur at a "point in the code" that
> doesn't really exist, because the compiler has transformed the code.
> That means invariants may be arbitrarily broken, locks may be held,
> etc.  Posix doesn't, and can't, guarantee that longjmping out of
> such a signal handler is safe.  In some cases it may work, but its
> hard to guarantee correctness, GC or not.
> 
> I believe that Java implementations that try to generate stack
> overflow exceptions usually handle this by always making sure that
> they encounter stack overflow exceptions at a known point.  For
> example, they check at the beginning of each function that the
> function, including any native library code it invokes, has enough
> stack space to run to completion.  This isn't entirely free, though
> it may be fairly cheap.  It still doesn't strike me as 100% solid,
> since the libc API doesn't really include maximum stack depth
> bounds, so you have to determine those empirically, and hope libc
> doesn't change unexpectedly.  And it's easy to miss a path through
> libc that has an unexpectedly deep call stack because something
> unexpected happened inside the library call.

No, it doesn't work that way.  If a stack overflow happens in libc
code, it won't be caught as a stack overflow exception.  Calls to
native code don't run in Java state, and any segfault in one results
in a crash dump.

> Even if it works, you still have the problem that Java code may have
> trouble dealing with the exception in unexpected places.

Unexpected like how?  HotSpot always bangs the stack at entry to a
method, and knows how much scratch space is needed.

Andrew.