RFR(M): 8170655: [posix] Fix minimum stack size computations
goetz.lindenmaier at sap.com
Sat Dec 3 18:17:18 UTC 2016
I would like to fix two issues of minimum stack size computation:
Please review and sponsor.
This are the issues I excluded from the "8169373: Work around linux NPTL stack guard error."
I wrote a lengthy explanation in the bug, trying to comment on what was
said in the other thread. I'll repeat it here, I think that's better for discussion.
Dan, thanks for improving the text, I use the improved variant here:
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev