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