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