jmx-dev RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Mon Oct 21 01:47:49 PDT 2013


On 18.10.2013 18:42, Mandy Chung wrote:
> On 10/16/2013 7:18 AM, Jaroslav Bachorik wrote:
>> Please, review this simple test change.
>>
>> The test tries to get the number of times a certain thread was blocked
>> during the test run and intermittently fails with the difference of 1
>> - the expected number is 4 but the reported number is 3.
>>
>> When updating the thread statistics (the blocked count in this case)
>> no lock is used so there might be stale data when the ThreadMXBean
>> retrieves the stats. The patch tries to workaround this problem by
>> retrying a few times with the added delay. The test will try to obtain
>> the correct result for at most 10 seconds - after that it will fail if
>> the retrieved blocked count does not equal the expected blocked count.
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-7197919
>> Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00
>
> Looks okay.   I notice that existing code that catches
> InterruptedException only sets testFailed to true but continue.  I think
> it might be good to fix them to return if IE is caught to fail-fast like
> what your fix does.

Unfortunately, it's not possible to directly return in those cases. The 
synchronization logic relies on the code passing through all the 
"signal"/"waitForSignal" pairs for the test to finish - otherwise the 
test might just hang. I have at least added loop breaks to fail a bit 
faster in case of IE.

-JB-

>
> Mandy



More information about the serviceability-dev mailing list