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

Gerald Thornbrugh gerald.thornbrugh at oracle.com
Wed Jul 27 13:48:35 UTC 2016


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.

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



More information about the hotspot-runtime-dev mailing list