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

[Gerald Thornbrugh]

Hi Everyone,

Here is the new webrev with the 1M change:

http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.02/ 
<http://cr.openjdk.java.net/%7Egthornbr/8161696/hotspot-webrev.02/>

Please let me know if you have questions or concerns.

Thanks,

jerry
> 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
>>>>
>>