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

[David Holmes]

On 27/07/2016 11:48 PM, Gerald Thornbrugh wrote:
> Hi Fred,
>
> Thanks for the information.
>
> How does everyone feel about implementing Fred's suggestion of a stack
> size of 1MB?
> As Fred states this not a complete fix but it would provide relief from
> this issue for the foreseeable future.

I can live with it but I think it is unnecessary.

Thanks,
David

>
> Thanks,
>
> Jerry
>> Hi Jerry,
>>
>> On 26/07/2016 22:55, Gerald Thornbrugh wrote:
>>> 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'm not the author of this test, but I can try to contribute my
>> two cents.
>>
>> I'm not seeing any particular reason to limit the stack size to
>> 320KB other than reducing time and resources required for this
>> test.
>>
>> Looking at the test history, Dmitry did the current version of the
>> test, but the "-Xss320k" argument was already there before Dmitry
>> re-wrote the test to fix 8042155. So it looks like a relic from
>> old code for which the rational has been lost.
>>
>> Regarding the test, limiting the stack size looks a good idea to
>> avoid wasting too much time and resources during testing. However,
>> I'm seeing to reason to make the stack size "as small as possible".
>> A 1MB stack size could already provide efficient improvement while
>> avoiding platform dependent stack size constraint (and I'll be
>> cursed for this by next generations of HotSpot developer as a
>> 1MB limitation could become completely unjustified in the future).
>>
>> Fred
>>
>>> 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
>>>
>