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

David Holmes david.holmes at oracle.com
Tue Dec 2 09:37:00 UTC 2014


On 1/12/2014 7:16 PM, Jaroslav Bachorik wrote:
> 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?

I guess so.  Still not sure why we see the println problem though - but 
don't have time to delve into it.

Thanks,
David

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


More information about the serviceability-dev mailing list