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

[Jaroslav Bachorik]

On 07/01/2014 11:01 PM, shanliang wrote:
> 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.

Yes, I see your point. Unless you are trying to use ThreadInfo for some 
hand-crafted synchronization you shouldn't hit this issue. But let's 
check what the ThreadInfo doc says about the reliability of the provided 
data.

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

Unfortunately yes. We had to do more compromises when testing the 
results provided by ThreadInfo since we were hitting the principle of 
uncertainty in the JVM world :(

-JB-

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