HotSpot has three cmd line options to set stack sizes (besides -Xss):
-XX:ThreadStackSize for threads executing Java code.
-XX:CompilerThreadStackSize for threads used by the JIT compilers.
-XX:VMThreadStackSize for threads executing VM internal tasks as gc.

All these flags should not be set to a value that leads to a stack overflow before user code can be executed. As the VM executes a  lot of code for initialization and also the JIT already compiles methods, considerable amounts of stack can be used during startup.  We must try to avoid stack overflows before startup is complete as error handling might not be properly in place yet.

Required minimum stack sizes depend on frame sizes and program execution paths. Frame sizes again depend on the C compiler used, the platform compiled for, and design decisions in interpreter, C1 and C2.

Required stack sizes also depend on option settings, e.g. with JVM/TI enabled, frames can get bigger. With inlining increased JIT compilers might do more optimizations leading to deeper call chains, etc. 

While the minimum stack sizes should reflect differences in Platform and compiler, they must not, and cannot, cover all possible option settings.

This change addresses two issues:

1. Fixed minimum stack size configuration

Currently, the minimum Java thread size is given in a constant per os/cpu platform for each of the three stack kinds. This number includes the size required for guard pages.

The guard pages are used for stack overflow detection.  They make up 4 zones on the stack: Red, Yellow, Reserved and Shadow pages. The Red, Yellow and Reserved pages are protected to detect stack overflows. The Shadow pages are just some extra space to allow methods that don't do a stack bang to execute.

Unfortunately, the size required for guard pages is not fixed at compile time. It depends on the concrete system the VM is started on. Thus the minimum sizes given can be too small to hold the guard pages.  This lead to errors in the past that were solved by introducing code that overruled the per-platform minimum stack size. This code nowadays is the MAX2() in os_posix.cpp:1114 and the SOLARIS special case further down. It uses the value (4 * BytesPerWord COMPILER2_PRESENT(+ 2)) * 4 * K) (os_posix.cpp:1117) as minimum required space for frames. Thereby it effectively overrules the minimum stack size settings given in the os/cpu constants, and there is currently no way to specify this size per platform.

This change proposes to fix this issue by specifying the space needed for stack frames in the os/cpu constants.  During startup, this number is increased by the space required for the guard pages. Thus, this takes into account the page size of the concrete system the VM runs on, and also eventual changes to the guard pages by the flags StackRed/Yellow/Reserved/Shadow/Pages.  This gives the opportunity to reduce the minimum stack sizes on systems with small pages.

Minimum stack size configuration is more simple with this change and valid for systems with any page size.

2. Stack guard pages not considered for compiler thread stacks

Compiler threads are Java threads.  The C++ class CompilerThread is a subclass of JavaThread. When a compiler thread is started, JavaThread::run() is executed which protects the red, yellow and reserved pages.

Since 8140520 the minimum stack sizes for Compiler and VM internal threads no longer include the space for the guard pages. This is correct for the VM internal threads, but not for the Compiler thread.

For the HotSpot C1 and C2 compilers it would be fine to reserve space for the Red/Yellow/Reserved pages, as they don't stack bang with the shadow page size.  But since introducing JVMCI, compilers written in Java can be running on the compiler threads. Therefore the shadow pages are needed, too.

As for the Java thread, this change uses a os/cpu constant for the required minimum space for compiler frames and then adds the zone sizes to the minimum stack sizes during startup.

New sizing:

The constants of the os/cpu minimum thread sizes are reduced by the default guard page sizes and then verified by starting the VM to assure the stack still suffices to get through startup.  Hotspot jtreg tests are passing. The overall sizes required (after adding guard pages) on the systems I have available get a bit smaller. In most cases the sizes even suffice to run simple programs as SpecJvm98. The table below gives the systems I tested and the required sizes reported when started with too small stacks.

<pre>
Thread kind:           Java       Compiler   VM
                       old  new   old  new   old  new

bsd     x86_64  dbg:   240  232    64   64    64  64
                opt:   240  232    64   64    64  64

linux   x86_64  dbg:   240  144    64  152    64  64
                opt:   232  136    64  144    64  64

solaris sparc   dbg:
                opt:   240  192   128  128   128 128

aix     ppc64   dbg:   512  512   384  512   128 128
                opt:   512  512   384  512   128 128
linux   ppc64   dbg:   512  384   128  384   128  64  
                opt:   512  384   128  384   128  64  
linux   ppc64le dbg:   512  384   128  384   128  64  
                opt:   512  384   128  384   128  64  

linux   s390    dbg:   236  140   128  184   128  32
                opt:   236  124   128  144   128  32
</pre>