RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object

David Holmes david.holmes at oracle.com
Thu Nov 27 00:43:57 UTC 2014


On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441
> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00
>
> The test fails because of System.out.println() may induce unexpected
> locking. The solution is to use an already existing LockFreeLogManager
> library class to collect the logs in the lock-free manner and print the
> logs only after all the test code has been run.

I seem to remember spending a lot of time on this test in the past, 
where the phaser usage was intended to ensure that we could not be seen 
to be blocking on the internal locks associated with the println. Where 
has this gone wrong?

What are the semantics of the lockfreelogger? When will we see its output?

Thanks,
David

> Thanks,
>
> -JB-


More information about the serviceability-dev mailing list