jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently

[Staffan Larsen]

Looks good!

Thanks,
/Staffan


On 1 jul 2014, at 10:48, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> On 07/01/2014 08:05 AM, Staffan Larsen wrote:
>> Jaroslav,
>> 
>> I wonder about this snippet:
>> 
>>  167         ti1 = mbean.getThreadInfo(tid);
>>  168         testBlocked(ti, () -> mbean.getThreadInfo(tid), lockName, lock1);
>>  169         ti = ti1;
>> 
>> When ti is used later (line 177) it may not have the values of the ThreadInfo that was actually ok:ed by testBlocked() (since testBlocked() loops). Is this a problem?
> 
> In this case it would probably make no difference since we are checking only for the reported number of thread blocked events being increased.
> 
> But using the actual up-to-date ThreadInfo makes the intentions clear and does not change the test outcome.
> 
> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.01
> 
> -JB-
> 
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> 
>> On 30 jun 2014, at 18:35, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>> 
>>> Please, review this test fix.
>>> 
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00
>>> 
>>> The problem described in this issue is that while a thread was blocked the blocked count reported by the MBean does not reflect it in very rare cases. However, it should be enough to wait a few moments to let the VM counter propagate the value to the MBean.
>>> 
>>> The attempted fix will cause the test to wait for the expected values instead of doing a one-time check. In the worst case the test will be timed out by the harness.
>>> 
>>> The rest of the changes just add more info to debug outputs.
>>> 
>>> Thanks,
>>> 
>>> -JB-
>> 
>