[9-dev] Request for review: JDK-8146128: compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig timeouts

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Sep 6 16:51:55 UTC 2016


Yes, this looks reasonable.

We may not need to check time between tests since you significantly 
reduced number of iterations.

I think we can go with these changes.

Thanks,
Vladimir

On 9/2/16 12:40 PM, Alexander Vorobyev wrote:
> Here is a new webrew:
> http://cr.openjdk.java.net/~avorobye/8146128/webrev.01/
>
> Changes:
>
> - timeout increased to 600;
>
> - TestAESMain now runs with 100 iterations and 1000 iterations for
> warm-up with -XX:CompileThresholdScaling=0.01 option added.
>
> Those changes allow our test to run much faster. Also, we still can be
> sure that methods are compiled (as I understand, by default compilation
> starts after 10000 iterations for server compiler, so settings listed
> above are suitable for us).
>
> About checking the remained time - how can we predict whether remained
> time is still enough for the next test case? Also, those test cases have
> different duration - it also makes our suggestions about time very
> vague. And if we just skip some test cases, we never know about it from
> test results (because whole test will be marked as passed).  I am not
> sure, if we should add such functionality for really rare cases when
> there is not enough time. What do you think?
>
>
> On 01.09.2016 21:44, Vladimir Kozlov wrote:
>> Yes, in addition to timeout increase.
>>
>> Because we can always find very slow platform (SPARC VM, for example)
>> on which any reasonable timeout may be not enough. It would be rare
>> cases with increased timeout so that skipping remaining tests is fine,
>> I think. You can't increase timeout to hours.
>>
>> Thanks,
>> Vladimir
>>
>> On 9/1/16 11:36 AM, Alexander Vorobyev wrote:
>>> Do you mean to stop the test execution if there is not enough time
>>> remained? Even if not all test cases finished?
>>>
>>>
>>> On 01.09.2016 21:15, Vladimir Kozlov wrote:
>>>> Yes, removing jdk90dev from to:
>>>>
>>>> 300 is not enough. From bug report:
>>>>
>>>> elapsed time (seconds): 482.214
>>>>
>>>> An other way to solve that is to check remaining time after each test
>>>> (forked VM) is executed and exit gracefully.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>
>>>>
>>>> On 9/1/16 11:13 AM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> The hotspot compiler changes should go to jdk9/hs-comp and not to
>>>>> 9-dev.
>>>>> Also hotspot-compiler-dev at openjdk.java.net alias should be used for
>>>>> compiler specific product and test changes.
>>>>>
>>>>> It is unclear from issue description/comment what is the root cause of
>>>>> failure and how it was fixed. Could you please add this information.
>>>>>
>>>>> Leonid
>>>>>
>>>>> On 01.09.2016 20:58, Alexander Vorobyev wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'd like review for JDK-8146128
>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8146128)
>>>>>>
>>>>>> Test passes with timeout increased. Looks like it times out in
>>>>>> sub-tests where AESIntrinsics are disabled (testNoUseAES(),
>>>>>> testNoUseAESIntrinsic()). The easiest way to fix this test is to
>>>>>> increase timeout.
>>>>>>
>>>>>> Run parameter was added:
>>>>>> @run main/othervm/timeout=300
>>>>>>
>>>>>>
>>>>>> Here is webrev:
>>>>>> http://cr.openjdk.java.net/~avorobye/8146128/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>


More information about the hotspot-compiler-dev mailing list