RFR 8029890: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails: Blocked thread has 4 blocked counts. Expected 3

Staffan Larsen staffan.larsen at oracle.com
Wed Dec 18 01:06:08 PST 2013


Looks good!

Thanks,
/Staffan

On 18 dec 2013, at 10:01, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> Thanks!
> 
> On 17.12.2013 14:25, Staffan Larsen wrote:
>> line 156: I think this should be: "testOk = false;”
> 
> Fixed.
> 
>> 
>> in checkBlocked(): after the loop, I don’t think you have get the block count again and check it. If you get here, the test has failed.
> 
> While it may, theoretically, happen that the blocked count suddenly gets refreshed even though it was stalled for 10 seconds before, it doesn't sound very realistic. I'm removing the after-the-loop check.
> 
> http://cr.openjdk.java.net/~jbachorik/8029890/webrev.02
> 
> -JB-
> 
>> 
>> /Staffan
>> 
>> 
>> On 17 dec 2013, at 11:53, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>> 
>>> On 17.12.2013 11:50, Jaroslav Bachorik wrote:
>>>> Please, review the following test fix.
>>>> 
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8029890
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8029809/webrev.00
>>> 
>>> Sorry, the correct webrev is
>>> http://cr.openjdk.java.net/~jbachorik/8029890/webrev.00
>>> 
>>>> 
>>>> The test fails intermittently due to ThreadMXBean.getThreadInfo()
>>>> blocking the tested thread from time to time. The solution is not to
>>>> invoke this method from within the tested thread and, in order to make
>>>> the test more readable and maintainable, replace the
>>>> ThreadExecutionSynchronizer with the standard j.u.c.Phaser.
>>>> 
>>>> Thanks,
>>>> 
>>>> -JB-
>>> 
>> 
> 



More information about the serviceability-dev mailing list