Looks good! Thanks, /Staffan
On 1 jul 2014, at 10:48, Jaroslav Bachorik <[email protected]> wrote: > 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- >> >
