RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out

David Holmes david.holmes at oracle.com
Wed Jun 24 09:22:27 UTC 2015


On 23/06/2015 5:33 PM, Jaroslav Bachorik wrote:
> Hi David,
>
> On 23.6.2015 08:04, David Holmes wrote:
>> On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote:
>>> Please, review the following test change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071487
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00
>>>
>>> GaugeMonitorDeadlockTest fails intermittently due data race - the call
>>> to monitorProxy.start() on L105 will eventually result in incrementing
>>> the GetCount attribute. If that happens before L109 had the chance to
>>> run the loop on L113-128 will become infinite. The initial value will
>>> contain the already incremented GetCount value and GetCount attribute
>>> value will not get further incremented.
>>
>> The reordering of the start() and initial observedProxy.getGetCount
>> seems reasonable.
>>
>> The changes to the timeout handling less so. The alarm code doesn't look
>> right to me. Each time you call check(true) in the loop you advance the
>> time when the alarm "goes off". ???
>
> Stupid me :( Thanks for catching this.
>
> http://cr.openjdk.java.net/~jbachorik/8071487/webrev.01

That looks better, but the Alarm class would benefit from some simple 
descriptive comments. I must admit I don't really see the need for 
introducing it.

Thanks,
David

> -JB-
>
>>
>> David
>>
>>
>>
>>> I took the liberty to fix the same issue in
>>> test/javax/management/monitor/StringMonitorDeadlockTest.java, not
>>> waiting for the real test failure.
>>>
>>> Thanks,
>>>
>>> -JB-
>


More information about the serviceability-dev mailing list