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

[Chris Plummer]

Hi Kumar,

I explained the formatting changein a previous email, but I see now the 
formatting change I did on line 82 makes it inconsistent with similar 
source on line 82, so I'll change it back.

thanks,

Chris

On 3/16/17 9:56 AM, Kumar Srinivasan wrote:
> 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
>>
>