On 07/01/2014 08:05 AM, Staffan Larsen wrote:
Jaroslav,
I wonder about this snippet:
167 ti1 = mbean.getThreadInfo(tid);
168 testBlocked(ti, () -> mbean.getThreadInfo(tid), lockName, lock1);
169 ti = ti1;
When ti is used later (line 177) it may not have the values of the ThreadInfo
that was actually ok:ed by testBlocked() (since testBlocked() loops). Is this a
problem?
In this case it would probably make no difference since we are checking
only for the reported number of thread blocked events being increased.
But using the actual up-to-date ThreadInfo makes the intentions clear
and does not change the test outcome.
Updated webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.01
-JB-
Thanks,
/Staffan
On 30 jun 2014, at 18:35, Jaroslav Bachorik <[email protected]>
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-
