JDK-8172731 : runtime/Thread/TooSmallStackSize.java fails on solaris-x64 with product build
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86_64
  • Submitted: 2017-01-12
  • Updated: 2017-02-09
  • Resolved: 2017-01-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9
10Fixed 9 b156Fixed
Related Reports
Relates :  
JDK-8170655 - [posix] Fix minimum stack size computations
Description
Test runtime/Thread/TooSmallStackSize.java fail on solaris-x64 when product binaries are tested with following error:
----------System.out:(17/3471)----------
*** Testing -XX:ThreadStackSize=16
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:ThreadStackSize=16 -version ]
PASSED: got expected error message with -XX:ThreadStackSize=16
*** Testing -XX:ThreadStackSize=32
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:ThreadStackSize=32 -version ]
PASSED: got expected error message with -XX:ThreadStackSize=32
*** Testing -XX:ThreadStackSize=144
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:ThreadStackSize=144 -version ]
PASSED: VM launched with -XX:ThreadStackSize=144
*** Testing -XX:CompilerThreadStackSize=16
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:CompilerThreadStackSize=16 -version ]
PASSED: got expected error message with -XX:CompilerThreadStackSize=16
*** Testing -XX:CompilerThreadStackSize=32
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:CompilerThreadStackSize=32 -version ]
PASSED: got expected error message with -XX:CompilerThreadStackSize=32
*** Testing -XX:CompilerThreadStackSize=300
Command line: [/export/home/aginfra/CommonData/TEST_JAVA_HOME/bin/java -d64 -cp /export/home/aginfra/sandbox/results/workDir/classes/0/runtime/Thread:/export/home/aginfra/CommonData/j2se_jdk/hotspot/test/runtime/Thread:/export/home/aginfra/sandbox/results/workDir/classes/0/test/lib:/export/home/aginfra/CommonData/j2se_jdk/test/lib:/export/home/aginfra/CommonData/jtreg_dir/lib/javatest.jar:/export/home/aginfra/CommonData/jtreg_dir/lib/jtreg.jar -XX:CompilerThreadStackSize=300 -version ]
----------System.err:(21/1050)----------
 stdout: [];
 stderr: []
 exitValue = 11

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:362)
	at TooSmallStackSize.checkMinStackAllowed(TooSmallStackSize.java:155)
	at TooSmallStackSize.main(TooSmallStackSize.java:189)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:538)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
	at java.base/java.lang.Thread.run(Thread.java:844)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

JavaTest Message: shutting down test
Comments
I had a closer look at the failures and we always fail in the C2 matcher in the generated method State::MachNodeGenerator(int) which basically consists of a *huge* switch statement matching opcodes. Turns out that with a product build we reserve lots of stack space on method entry: 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push %rbp 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push %r15 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub $0x53ba8,%rsp This requires ~335k of stack space whereas a fastdebug build only requires ~15k for the same method: 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push %rbp 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub $0x9430,%rsp This is consistent with my findings that a fastdebug VM requires a CompilerThreadStackSize of 155k whereas a product build requires 384k.
16-01-2017
@@ -87,11 +87,11 @@ #define MAX_PATH (2 * K) // Minimum usable stack sizes required to get to user code. Space for // HotSpot guard pages is added later. #ifdef _LP64 -size_t os::Posix::_compiler_thread_min_stack_allowed = 202 * K; +size_t os::Posix::_compiler_thread_min_stack_allowed = 325 * K; size_t os::Posix::_java_thread_min_stack_allowed = 48 * K; size_t os::Posix::_vm_internal_thread_min_stack_allowed = 224 * K; #else size_t os::Posix::_compiler_thread_min_stack_allowed = 32 * K; size_t os::Posix::_java_thread_min_stack_allowed = 32 * K; So the "202" value works for non-product builds, but you need "325" for product builds. I think you need to make this change conditional on whether we're building product versus non-product. Update: What I suspect is going on here is that the non-product Solaris X64 build is adding more pages as part of the guard page addition and that's what is making the "202" value "work". Update: The latest webrev changed from "324" -> "325" so I've tweaked the above comment.
13-01-2017
Yes, fastdebug builds use 22 StackShadowPages instead of 20 which are used for product builds. The debug builds only work "by accident" because there are more shadow pages. I don't think the fix should be made dependent on the build type.
13-01-2017
$ /java/re/jdk/1.9.0/latest/binaries/solaris-x64/bin/java -XX:CompilerThreadStackSize=380 -version ^ZSegmentation Fault (core dumped) $ /java/re/jdk/1.9.0/latest/binaries/solaris-x64/bin/java -XX:CompilerThreadStackSize=381 -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+152) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+152, mixed mode) Looks like the new minimum value works on my Solaris X64 server.
13-01-2017
The test fails because the VM crashes with a CompilerThreadStackSize of 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not enough to start the VM on Solaris x86. This didn't show up when the fix was integrated because the it was only tested with debug builds. Setting guard pages to the minimum size via "-XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2" requires a CompilerThreadStackSize of at least 381k to not crash at startup with a product build but the VM checks for >= 260k. I increased the value of os::Posix::_compiler_thread_min_stack_allowed accordingly by 122 (due to rounding) such that the minimum CompilerThreadStackSize is 381k. http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
13-01-2017
This regression is likely caused by the following fix: JDK-8170655 [posix] Fix minimum stack size computations That fix changed the way that the minimum thread stack sizes are calculated. The minimum thread stack sizes are different between release, fastdebug and slowdebug builds. The value -XX:CompilerThreadStackSize=300 is the minimum recommended: $ /java/re/jdk/1.9.0/latest/binaries/solaris-x64/bin/java -XX:CompilerThreadStackSize=1 The CompilerThreadStackSize specified is too small. Specify at least 300k Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. However, when I run with that command on the Solaris X64 server machine in my lab: $ /java/re/jdk/1.9.0/latest/binaries/solaris-x64/bin/java -XX:CompilerThreadStackSize=300 -version Segmentation Fault (core dumped) it crashes without an hs_err_pid file. $ /java/re/jdk/1.9.0/latest/binaries/solaris-x64/bin/java -XX:CompilerThreadStackSize=301 -version # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000000008f6000, pid=6236, tid=71 # # JRE version: Java(TM) SE Runtime Environment (9.0+152) (build 9-ea+152) # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+152, mixed mode, tiered, compressed oops, g1 gc, solaris-amd64) # Problematic frame: # C 0x00000000008f6000 # # Core dump will be written. Default location: /work/shared/bug_hunt/8167108/SMR_prototype/hotspot/core or core.6236 # # An error report file with more information is saved as: # /work/shared/bug_hunt/8167108/SMR_prototype/hotspot/hs_err_pid6236.log Phoning home... Using server: 10.161.186.18, port 4711 java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+152) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+152, mixed mode) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # I suspect that something has changed since the fix for JDK-8170655 was pushed since I did not see any failures like this.
13-01-2017
With a fastdebug build: The CompilerThreadStackSize specified is too small. Specify at least 308k Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
13-01-2017
When running with a product build: java -XX:CompilerThreadStackSize=300 -version results in: # SIGSEGV (0xb) at pc=0xffff80ff4eb472fa, pid=58102, tid=18 # # JRE version: Java(TM) SE Runtime Environment (9.0) (build 9-internal+0-2017-01-12-204111.lmesnik.8172710) # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-internal+0-2017-01-12-204111.lmesnik.8172710, mixed mode, tiered, compressed oops, g1 gc, solaris-amd64) # Problematic frame: # V [libjvm.so+0xb472fa] MachNode*State::MachNodeGenerator(int)+0xf6aa Current thread (0x0000000000768800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=18, stack(0xffff80ffbc553000,0xffff80ffbc59e000)] Current CompileTask: C2: 145 20 4 java.lang.StringLatin1::hashCode (42 bytes) Stack: [0xffff80ffbc553000,0xffff80ffbc59e000], sp=0xffff80ffbc5462f0, free space=18014398509481932k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xb472fa] MachNode*State::MachNodeGenerator(int)+0xf6aa V [libjvm.so+0x1799804] MachNode*Matcher::ReduceInst(State*,int,Node*&)+0x44 V [libjvm.so+0x17989b0] MachNode*Matcher::match_tree(const Node*)+0x4e0 V [libjvm.so+0x1791ca5] void Matcher::match()+0xd55 V [libjvm.so+0xfca183] void Compile::Code_Gen()+0x83 V [libjvm.so+0xfc37b7] Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool,DirectiveSet*)+0xfb7 V [libjvm.so+0xea4a52] void C2Compiler::compile_method(ciEnv*,ciMethod*,int,DirectiveSet*)+0xe2 V [libjvm.so+0xfdb398] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0x828 V [libjvm.so+0xfda219] void CompileBroker::compiler_thread_loop()+0x469 V [libjvm.so+0x1a5807f] void JavaThread::thread_main_inner()+0xdf V [libjvm.so+0x1a57f7a] void JavaThread::run()+0x3aa V [libjvm.so+0x1855ca0] thread_native_entry+0x240 C [libc.so.1+0x188d81] _thrp_setup+0xa5 C [libc.so.1+0x189060] _lwp_start+0x0 C 0x0000000000000000
13-01-2017