RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out
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.
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
>>> I took the liberty to fix the same issue in
>>> test/javax/management/monitor/StringMonitorDeadlockTest.java, not
>>> waiting for the real test failure.
More information about the serviceability-dev