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

[Jaroslav Bachorik]

On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote:
> On 11/27/2014 01:43 AM, David Holmes wrote:
>> 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?
>
> The remaining problem is the usage of System.out.print[ln]() inside the
> test threads. System.out.print[ln]() might involve blocking the calling
> thread and eg. create false positives when the test is waiting for a
> thread to enter the blocked state.
>
>>
>> What are the semantics of the lockfreelogger? When will we see its
>> output?
>
> It is using thread local lists of the logging records. Each logging
> record has an id which is unique and monotonous over all the threads ->
> an AtomicInteger instance is used to achieve this.
>
> You can retrieve the log output (ordered by the log record id) by
> calling LockFreeLogManager.toString().
>
> Review for the LockFreeLogManager is available here
> [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html]

David, are you ok with this change then?

Thanks,

-JB-

>
>
> -JB-
>
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>>
>>> -JB-
>