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

[shanliang]

Jaroslav Bachorik wrote:
> On 07/01/2014 09:20 PM, shanliang wrote:
>> So the issue (race cases) is from the implementation and detected by the
>> test, it meant that the thread info could be incorrect in some cases,
>> and your fix is to ask the test to try again in this case.
>
> Yes. That should give the counters time to propagate.
>
>>
>> What is the real cause? if it is not worth or impossible to fix, should
>> we give a warning in the ThreadMXBean Javadoc? or for some reason this
>> could be ignored?
>
> If you check the hotspot sources you would see that the various thread 
> related counters are not updated under any lock (probably the 
> performance would suffer greatly). Therefore, in very rare cases you 
> could get stale data in ThreadInfo.
So it is possible but very rare for a user to get incorrect info, and 
seems impossible to fix it, my questions were "should we give a warning 
in the ThreadMXBean Javadoc, or for some reason this could be ignored?" 
I can understand the difficulty, just thought that it might be helpful 
to give user some info.
>
>>
>> I am looking at JDK-8048215
>> <https://bugs.openjdk.java.net/browse/JDK-8048215> and thinking that it
>> might be same issue.
>
> With the lock info it might be even more complicated. Any 
> synchronization primitives you use in the test may influence the 
> results - I was burned pretty badly by Phaser and CyclicBarrier in 
> such tests ...
If difficult to fix in the implementation, then re-try is a way to make 
the test pass.

Shanliang
>
> -JB-
>
>>
>> Shanliang
>>
>>
>> Jaroslav Bachorik 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-
>>
>