RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again

[David Holmes]

Hi Jaroslav,

On 23/12/2013 10:42 PM, Jaroslav Bachorik wrote:
> Please, review the following test fix:
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8030847
> Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/
>
> The root cause of the intermittent failures of this test is the fact
> that there is a lot of hidden places in JDK classes when the checked
> thread can get BLOCKED - and it will distort the blocked count and the
> test will fail. The ones identified in this case were:
>
> - ThreadMXBean.getThreadInfo()
> - System.out.println()
> - Phaser.arriveAndAwaitAdvance()
>
> Whether the thread gets blocked or not depends on many variables and
> this makes the failure very intermittent.
>
> The fix consists of:
> - not using ThreadMXBean.getThreadInfo() from within the tested thread
> - not using System.out.println() (or any other kind of output) in the
> tested thread
> - not using Phaser to synchronize the tested thread and the control thread
>
> The toughest part is to replace Phaser for the synchronization purposes
> with a similar construct which would not block the thread when waiting
> for the other party. CyclicBarrier didn't work either as probably
> wouldn't not any other solution based on java.util.concurrent locks.
>
> The TwoPartySynchronizer provides the block-free synchronization and is
> based on atomics and Thread.wait(). It is not a general purpose
> replacement for Phaser or CyclicBarrier but it works very well for
> exactly two parties needing progress synchronization and not wanting to
> block any of the parties.

I see you actually meant Thread.sleep, which does of course block the 
thread but doesn't put it into the problematic "blocked" state that 
affects the blocked-count. That said I don't understand why this problem 
exists given that by definition the use of any of the synchronizers 
(based on park()) should not affect the blocked count:

getBlockedCount(): Returns the total number of times that the thread 
associated with this ThreadInfo blocked to enter or reenter a monitor.

None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount 
should not be being updated. If it is then that is a spec or 
implementation bug in itself :(

David