RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k

Gerald Thornbrugh gerald.thornbrugh at oracle.com
Wed Jul 27 02:55:53 UTC 2016


Hi David,
> Hi Jerry,
>
> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote:
>> Hi Everyone,
>>
>> I would like to have the following change reviewed:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696
>>
>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/
>> <http://cr.openjdk.java.net/%7Egthornbr/8161696/hotspot-webrev.01/>
>>
>> The stack size for this test needs to be increased to 384K for some
>> platforms.
>
> Is there a specific reason we set -Xss in the first place instead of 
> just taking the platform defaults? If the platform stack settings 
> change this test may need updating again.

It was my understand (maybe incorrectly) that setting -Xss was an 
attempt to limit the memory and time
resources the test takes.  Using the smallest stack size allowable will 
allocate less memory and reduce the
amount of time the test takes.  Since I think Fred wrote the test he 
would know better than I would.

Fred, what is the reason behind specifying "-Xss" for this test?

I have thought about the test harness setting an environment variable 
and/or a java property to the correct
minimum values for "-Xss" depending upon the architecture the test is 
running on.  The tests could then use
the value to start each test. That way each test could be tailored for 
the specific architecture. After looking into
this it looks the implementation would be significant and would be 
outside the scope of this bug fix.

Thanks,

Jerry
>
> Thanks,
> David
>
>> My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770
>> moved the functionality
>> from the testme.sh script to exeinvoke.c so the dependency for a local
>> compiler could be removed.
>> Because of this the stack size change needs to be applied to exeinvoke.c
>> file instead of the testme.sh file.
>>
>> Please let me know if you have any questions or concerns.
>>
>> Thanks,
>>
>> Jerry



More information about the hotspot-runtime-dev mailing list