RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue Jan 22 20:32:28 UTC 2019


Hi Alex,

It looks good to me.

Thanks,
Serguei


On 1/17/19 12:21 PM, Alex Menkov wrote:
> Hi Gary,
>
> On 01/17/2019 10:53, Gary Adams wrote:
>> I like the fact that test.timeout.factor is applied as a multiplier.
>>
>> It's not clear why an upper limit had to be added.
>
> As you noted there 3 cases where Thread.join() is called, but the 
> expected behavior is different. objWaiterThr2 and popFrameClsThr are 
> expected to exit, but objWaiterThr1 is expected to be alive after join 
> (i.e. the call is expected to take the time specified). I don't want 
> to increase the test run time (for timeout.factor == 10 it would take 
> 18 extra seconds), so I restricted the timeout for the case.
>
>> Is that 50 or 5 seconds?
>
> Thank you for the catch. It should be 5 seconds (5000 ms)
>
> Updated webrev:
> http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev.02/
>
> --alex
>
>>
>>   148             objWaiterThr1.join(Math.min(WAIT_TIME, 50000));
>>
>> Why are the other wait times not limited?
>>
>>   136             objWaiterThr2.join(WAIT_TIME);
>>
>> ...
>>
>>   169                 popFrameClsThr.join(WAIT_TIME);
>>
>>
>> If you need to apply the upper limit, then it would be better to 
>> apply it
>> at the beginning.
>>
>>    38     static final long WAIT_TIME = 
>> Math.min(Utils.adjustTimeout(2000),5000);
>>
>>
>>
>>
>>
>> On 1/16/19, 6:28 PM, Alex Menkov wrote:
>>> Hi all,
>>>
>>> please review a fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8216386
>>> webrev:
>>> http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/
>>>
>>> The fix updates WAIT_TIME to depend on test.timeout.factor system 
>>> property.
>>> WAIT_TIME value is used as argument of Thread.join().
>>> For the case when the thread is expected to be alive (i.e. 
>>> Thread.join() exits by timeout) the timeout value is restricted by 5 
>>> seconds to avoid long run time with big timeout.factor values.
>>>
>>> --alex
>>



More information about the serviceability-dev mailing list