[Gc] Can sigaltstack be used in a GC registered thread?
aph at redhat.com
Mon May 21 08:49:29 PDT 2012
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.
More information about the Gc