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

[Jaroslav Bachorik]

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.

>
> 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 ...

-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-
>