JDK-8204478 : VMThreadStackSize failing at max range
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2018-06-06
  • Updated: 2019-08-15
  • Resolved: 2019-02-26
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 13
13Resolved
Related Reports
Relates :  
JDK-8219789 - [TESTBUG] TestOptionsWithRanges.java produces hs_err_pidXXXXX.log file for VMThreadStackSize=9007199254740991
Relates :  
JDK-8140520 - segfault on solaris-amd64 with "-XX:VMThreadStackSize=1" option
Description
"java -XX:+PrintFlagsRanges -version" reports:

     intx VMThreadStackSize                                  [ 0                         ...          9007199254740991 ]                         {pd product} {default}

but "java -XX:VMThreadStackSize=9007199254740991 -version" results in:

# ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:VMThreadStackSize=9007199254740991 -version
[0.006s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 9007199254740992k, guardsize: 4k, detached.
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create worker GC thread. Out of system resources.
# An error report file with more information is saved as:
# /Volumes/Work/bugs/8195097/jdk11_rehn/hs_err_pid18970.log
Comments
The reason -XX:VMThreadStackSize=9007199254740991 passes TestOptionsWithRanges.java is that the java process in this case will exit with code=1, which is silently ignored by the test (unless the output is null). Though it will, confusingly, produce an hs_err_pidXXXXXXX file. If we exclude VMThreadStackSize at max range in the test, we will avoid this confusing case, and seems to me the best solution (even though the TestOptionsWithRanges.java technically passes), but that should be handled in a separate issue, as this one is technically "not an issue" Filed JDK-8219789
26-02-2019
The max setting for VMThreadStackSize is dependent on OS/system setup and does not make sense to be tested at max theoretical value. We need to exclude the max range test for this flag from /test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java just as we already do with many other: /* * Exclude below options as their maximum value would consume too much memory * and would affect other tests that run in parallel. */ excludeTestMaxRange("ConcGCThreads"); excludeTestMaxRange("G1ConcRefinementThreads"); excludeTestMaxRange("G1RSetRegionEntries"); excludeTestMaxRange("G1RSetSparseRegionEntries"); excludeTestMaxRange("G1UpdateBufferSize"); excludeTestMaxRange("InitialBootClassLoaderMetaspaceSize"); excludeTestMaxRange("InitialHeapSize"); excludeTestMaxRange("MaxHeapSize"); excludeTestMaxRange("MaxRAM"); excludeTestMaxRange("NewSize"); excludeTestMaxRange("OldSize"); excludeTestMaxRange("ParallelGCThreads"); excludeTestMaxRange("TLABSize"); /* * Remove parameters controlling the code cache. As these * parameters have implications on the physical memory * reserved by the VM, setting them to large values may hang * the system and/or may cause concurrently executed tests to * fail. These parameters are rigorously checked when the code * cache is initialized (see * hotspot/src/shared/vm/code/codeCache.cpp), therefore * omitting testing for them does not pose a problem. */ excludeTestMaxRange("InitialCodeCacheSize"); excludeTestMaxRange("CodeCacheMinimumUseSpace"); excludeTestMaxRange("ReservedCodeCacheSize"); excludeTestMaxRange("NonProfiledCodeHeapSize"); excludeTestMaxRange("ProfiledCodeHeapSize"); excludeTestMaxRange("NonNMethodCodeHeapSize"); excludeTestMaxRange("CodeCacheExpansionSize");
22-02-2019
Not sure I should post this here because it seems a different issue: With latest 13, I am sometimes(?) getting a test failure with runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. In any case, even if the test passes, there are hs_err files in the scratch directories. I.e. $ rm -rf JT*; export JT_JAVA=java && ~/Downloads/jtreg/bin/jtreg -J-Djavatest.maxOutputSize=1000000 -testjdk:[...]/build/linux-x86_64-server-fastdebug/images/jdk/ -v -conc:8 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java [...] Passed. Execution successful Test results: passed: 10 but $ find JTwork -name 'hs_err*' JTwork/scratch/3/hs_err_pid1216.log JTwork/scratch/3/hs_err_pid1184.log JTwork/scratch/3/hs_err_pid1209.log I.e. the test should probably not testing the bounds of VMThreadStackSize. Contents of one of the hs_err files: # # There is insufficient memory for the Java Runtime Environment to continue. # Cannot create worker GC thread. Out of system resources. # Possible reasons: # The system is out of physical RAM or swap space # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap # Possible solutions: # Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss) # Set larger code cache with -XX:ReservedCodeCacheSize= # This output file may be truncated or incomplete. # # Out of Memory Error (...src/hotspot/share/gc/shared/workerManager.hpp:91), pid=1184, tid=1190 # # JRE version: (13.0) (fastdebug build ) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 13-internal+0-adhoc.tschatzl.openjdk, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/tschatzl/Downloads/openjdk/test/hotspot/jtreg/JTwork/scratch/3/core.1184) # --------------- S U M M A R Y ------------ Command Line: -Xmx1024m -XX:-ZapUnusedHeapArea -XX:+UseG1GC -XX:VMThreadStackSize=9007199254740991 optionsvalidation.JVMStartup Note the really large VMThreadStackSize value.
13-12-2018
I don't see any bug. There's no a-priori set upper limit on the stacksize but if it is too big for your system then obviously you will get failures. And why is this filed in JVMTI ??
11-06-2018
See src/hotspot/share/runtime/globals.hpp product_pd(intx, VMThreadStackSize, \ "Non-Java Thread Stack Size (in Kbytes)") \ range(0, max_intx/(1 * K)) \ The value printed is merely the range for a valid integer, not an actual limit of what can be used for stack size. For a typical platform default, see src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp define_pd_global(intx, VMThreadStackSize, 1024);
11-06-2018