Many stack overflow problems have been fixed using a more general method
of detecting stack overflow from Java code.  The VM does not detect stack
overflow from native code however.   If you get a segmentation fault or
"An irrecoverable stack overflow has occurred", you may need more space to
run your native code if it has reached the top of a Java stack.  There is a
tuning parameter -XX:StackShadowPages=n that you can increase from 3 to what
the native code requires so that stack overflow is detected and has room
to throw the exception.
Build : 1.4.1-b14 (Hopper Beta)
Test : nsk/regression/b4278848
TestBase : testbase_nsk
VM : client VM
Mode : mixed,  comp
OS :  solx86

Steps to reproduce :
1. cd /net/sqesvr.sfbay/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit {JAVA_HOME}

Error output:
--------------------
sh doit.sh

/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHANGINGJAVA -client -Xmixed b4278848

Segmentation Fault - core dumped
Status = 139
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHANGINGJAVA -client -Xcomp b4278848

Segmentation Fault - core dumped
Status = 139
------------------------------------------------

 xxxxx@xxxxx  2002-06-05

N/A

This test is a stress test for stack overflow errors in native code. We will
look into it, but it is not a Hopper showstopper.

The test fails in -Xint mode as well.

 xxxxx@xxxxx  2002-06-17


 xxxxx@xxxxx  has suggested that we bang the stack a configurable
number of pages ahead in the JavaCalls::call stub and maintaining that number of
banged pages both in the interpreter and both compilers. Currently C2 does this
in their I2C adapters but the interpreter and C1 do not. This is probably the
best possible solution for stack overflow problems (which are not solvable in
the general case) and would simplify the associated logic on both platforms.

 xxxxx@xxxxx  2002-06-21

The changes above have been applied to the hotspot compilers and interpreter and
this and  xxxxx  stack overflow detection bugs are fixed.  This general solution
has been applied to both compilers and the interpreter so they should all
detect and throw StackOverflowError the same.  A new hotspot tuning variable
-XX:StackShadowPages=n can be increased for deeply nested native code near the
stack limit, to detect stack overflow from the java caller.  The value of 'n'
is number of pages the deeply nested native code needs, and should be greater
than 3 which is the number of pages the VM and known runtime code needs.

Several  xxxxx  bugs have been made a duplicate of this bug.  The  xxxxx  bugs have
different failure modes, but the root cause was the same.  See the "see also"
list.

 xxxxx@xxxxx  2002-10-16