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.
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?
I am looking at JDK-8048215
<https://bugs.openjdk.java.net/browse/JDK-8048215> and thinking that it
might be same issue.
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-
