RFR(XS): 8139900: [TESTBUG] Remove G1UpdateBufferSize and InitialBootClassLoaderMetaspaceSize from TestOptionsWithRanges

[Dmitry Dmitriev]

Hi Sangheon,

Thank you for the review!

About 'timeout' value and compiler flags: probably this will be not 
needed, because I am planning to submit review for another RFR which 
improve processing of numeric flags in HotSpot VM which will also affect 
TestOptionsWithRanges in a good way, i.e. execution time of this test 
will be less.

Thanks,
Dmitry

On 20.10.2015 20:29, sangheon.kim wrote:
> Hi Dmitry,
>
> I was also wondered about addTypeDependency() but I'm clear now.
> Changes look good, reviewed.
>
> When we merge with 'compiler' part, the 'timeout' value would be 
> increased again.
>
> Thanks,
> Sangheon
>
>
> On 10/20/2015 10:23 AM, Dmitry Dmitriev wrote:
>> Gerard, thank you for the review!
>>
>> Dmitry
>>
>> On 20.10.2015 20:21, gerard ziemski wrote:
>>>
>>>
>>> On 10/20/2015 12:14 PM, Dmitry Dmitriev wrote:
>>>> Hi Gerard,
>>>>
>>>> Thank you for looking into that!
>>>>
>>>> On 20.10.2015 19:38, gerard ziemski wrote:
>>>>> hi Dmitry,
>>>>>
>>>>> Thank you very much for looking into this and making the test more 
>>>>> robust.
>>>>>
>>>>> #1 Did you intend to incluse the change in
>>>>> "test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java" 
>>>>> removing
>>>>> addTypeDependency()? Can you please explain that code removal?
>>>> Yes, sorry that I miss that in an e-mail. This was added for C1&C2 
>>>> flags. But -Xcomp can dramatically increase execution
>>>> time and since soon we will get compiler flags in hs-rt repo I 
>>>> decided to remove that. I will think about more precise
>>>> approach for that.
>>>>
>>>>>
>>>>> #2 How sure are we that 780 sec is enough if the arm's tests are 
>>>>> still in progress?
>>>>
>>>> I think yes, because "G1UpdateBufferSize" and 
>>>> "InitialBootClassLoaderMetaspaceSize" are removed and test time
>>>> significantly goes down. Result for linux-arm-vfp-sflt are looks 
>>>> good. Several other arms are stuck in submitted state,
>>>> but I hope they will be ran until tomorrow.
>>>>
>>>
>>> I would be more comfortable with more than a single test run that 
>>> doesn't time out on ARM, but we can always come back and revisit I 
>>> suppose - this test is not ON by default, so we can take time to 
>>> zero in.
>>>
>>> Reviewed (with small "r")
>>>
>>>
>>> cheers
>>>
>>>
>>>> Thanks,
>>>> Dmitry
>>>>>
>>>>>
>>>>> cheers
>>>>>
>>>>> On 10/20/2015 11:06 AM, Dmitry Dmitriev wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for TestOptionsWithRanges.java test. In this 
>>>>>> fix I remove two flags("G1UpdateBufferSize",
>>>>>> "InitialBootClassLoaderMetaspaceSize") from testing because their 
>>>>>> maximum value would consume too much memory and take a
>>>>>> lot of time. Also I increase timeout value for the test, since 
>>>>>> number of flags with ranges were increased recently.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8139900
>>>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8139900/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Eddmitriev/8139900/webrev.00/>
>>>>>> Testing: ran on all platforms including arm's(test for few arm's 
>>>>>> are still in progress).
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>
>>>>
>>
>