RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

Kumar Srinivasan kumar.x.srinivasan at oracle.com
Thu Mar 16 16:56:46 UTC 2017


Hello,

I can't recall why  String vs int.
Formatting seems off,

   81         tr = doExec(javaCmd, "-Xms64m", "-Xmx512m",
   82                 "-Xss" + stackSize + "k", "-XshowSettings", "-jar", testJar.getAbsolutePath());
   83         containsAllOptions(tr);
   84         if (!tr.isOK()) {
   85             System.out.println(tr);
   86             throw new RuntimeException("test fails");
   87         }
   88         tr = doExec(javaCmd, "-Xms65536k", "-Xmx712m",
   89                     "-Xss" + (stackSize * 1024), "-XshowSettings", "-jar", testJar.getAbsolutePath());

Otherwise looks good to me.

Kumar


> Hello,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8176797
> http://cr.openjdk.java.net/~cjplummer/8176797/webrev.00/webrev.jdk
>
> After fixing 8175342 (see the other RFR I just posted), this test 
> started to fail instead of assert. The problem is 256000 is too small 
> of a stack size on the platform in question. It needs to be at least 
> 256k.
>
> The test has a "stackSize" local variable that is the String "256". It 
> runs the jvm with -Xss of this size, appending "k" to it on one run 
> and "000" in the next. The -Xss256k version is fine. The -Xss256000 
> version is not. I'm not sure why the test chose to specify the 
> stackSize as a String instead of an int. As part of this fix I changed 
> it to an int, and just multiply it by 1024 in the case where -Xss is 
> specified with a byte size rather the an k size. The test passes now 
> on the platform where it was failing.
>
> thanks,
>
> Chris
>



More information about the hotspot-runtime-dev mailing list