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 core-libs-dev
mailing list