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.
Thanks,
-JB-
