JDK-8136766 : Enable ThreadStackSize range test
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-18
  • Updated: 2016-10-06
  • Resolved: 2016-09-16
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 9
9 b139Fixed
Related Reports
Blocks :  
JDK-8140520 - segfault on solaris-amd64 with "-XX:VMThreadStackSize=1" option
Relates :  
JDK-8078556 - Runtime: implement ranges (optionally constraints) for those flags that have them missing
Relates :  
JDK-8140520 - segfault on solaris-amd64 with "-XX:VMThreadStackSize=1" option
Description
For JDK-8078556 we implemented the ranges for missing runtime flags, but ThreadStackSize, has platform dependent behavior where some platforms require it to be > 0, but on Windows some tests try to instantiate the VM with the value == 0 to let the OS come up with default. This causes problem from hotspot/test/runtime/CommandLine point of view. For now we implement the range as range(0, max_intx-os::vm_page_size()), but that needs to be made platform dependent.
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5bddf69330f2 User: lana Date: 2016-10-05 20:01:40 +0000
05-10-2016
URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5bddf69330f2 User: gziemski Date: 2016-09-16 18:40:50 +0000
16-09-2016
Once JDK-8140520 is fixed, then we can trivially implement the range as (0, MAX)
01-04-2016
The JPRT log shows this: ( eval C:/jprt/T/P1/195746.gerard/testproduct/windows_i586_6.2-fastdebug/bin/java -Xmx128M -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseSerialGC -server -jar GCBasher.jar -time:300000 ) Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. intx ThreadStackSize=0 is outside the allowed range [ 1 ... 2147479551 ] That failure happened when the lower range of ThreadStackSize was one (1) and it is currently zero (0). That must have been fixed with a different bug ID. When the ThreadStackSize == 0, that means use the platform default. The same is true for CompilerThreadStackSize and CompilerThreadStackSize options. The suggested change from Goetz will break that behavior. The lower range for the three thread stack options must remain at zero in order for the current semantics of "== 0" to work.
12-02-2016
Email from Lindenmaier, Goetz: --------------------------------------------------------------------------------------------------- Hi Gerald, I think the code below would be a good fix for ThreadStackSize. There should be at least 4 pages, red, yellow, shadow, and some space to be used by the thread. And the values should be divided by 1K. product_pd(intx, ThreadStackSize, \ "Thread Stack Size (in Kbytes)") \ - range(0, max_intx-os::vm_page_size()) \ + range((4*os::vm_page_size())/(1 * K), \ + (max_intx-os::vm_page_size())/(1 * K)) \ \ product_pd(intx, VMThreadStackSize, \ - "Non-Java Thread Stack Size (in Kbytes)") \ + "Non-Java Thread Stack Size (in Kbytes). 0: an ergonomic default" \ + " is used.") \ range(0, max_intx/(1 * K)) \ \ product_pd(intx, CompilerThreadStackSize, \ I also extended the comment for VMThreadStackSize. With this, the range test passes on the ppc machines with 64K page size. It seems to ignore the crashes because of too few memory, but I still find all the hs_err files. Your change resolves my issue https://bugs.openjdk.java.net/browse/JDK-8134396 thanks for that! Best regards,
15-10-2015