HP-UX Programmer's Guide for Java 2

situation in the native code itself, even if no Java™ code was ever run on the primordial
thread.
Another point to consider is the effect of maxssiz on the overall amount of writeable
data space available to the application. The kernel automatically protects some memory
above maxssiz away from the primordial stack base to enforce the maxssiz limit. If the
maxssiz is very large, this space between the base and the protected stack top is
permanently reserved for potential stack space, and it is not available for any other
writeable data use such as C heap, Java™ heap, or other thread stacks. Therefore if you
need to have the maximum amount of writeable data space available to your application,
you may want to consider reducing the maxssiz. Remember, though, that maxssiz affects
all applications running on the system.
Example
Consider the following example. An application calls JNI_CreateJavaVM from the
primordial thread, which installs a stack overflow check at more or less 2MB above the
JNI_CreateJavaVM frame. The application then makes function calls via recursion
or otherwise that result in a very deep stack on the same thread independent of calling
back into Java™. The stack usage could cross the JVM-imposed primordial thread stack
size limit of 2M and cause a stack overflow situation in the native code itself. In this
case the JVM cannot take any action to resolve the problem, and the process aborts
with the message:
"An irrecoverable stack overflow has occurred."
You need to distinguish stack overflow failures in the primordial thread from those
occurring in other threads. If the overflow is in a Java™ thread, the error log generated
will report the current Java™ thread, which can be used to identify the thread that
caused the stack overflow failure. In the JVM diagnostic output, you would see a
message like this:
An irrecoverable stack overflow has occurred.
An unexpected exception has been detected in native code outside the VM.Unexpected Signal : 10
occurred at PC=0x2D10
Function=__d_trap
Library=./crjvmzon
Current Java™ thread:
"main" prio=7 tid=4000a1b8 nid=1 lwp_id=127233 runnable [0x00000000..0x6fff0b08]
Dynamic libraries:
./crjvmzon
text:0x00001000-0x00003db4 data:0x40001000-0x400014b4
/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl
text:0xc2000000-0xc2c67000 data:0x6fe0b000-0x6ffab000
[...]
Above, you can see that the error happened on the "main" thread, that is, the one that
called JNI_CreateJavaVM.
Workarounds
Here are three suggestions to work around a stack overflow problem in the main thread,
listed from most desirable to least.
58 Using Java™ 2 JNI on HP-UX