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-
