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

[David Holmes]

On 3/12/2014 1:51 AM, Jaroslav Bachorik wrote:
> On 12/02/2014 10:37 AM, David Holmes wrote:
>> 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!
>
> PrintStream and Writer are full of synchronized blocks. When on use them
> in multithreaded environment an occasional blocking might occur.
>
> For example, in Locks.java, 'LockAThread' and 'LockBThread' threads run
> concurrently, both of them outputting some log info via System.out. So
> it may happen that when asserting the 'LockAThread' thread state in
> 'checkBlockedObject' the thread is in blocked state thanks to blocking
> on the output stream internals rather than on the test monitor.

Yes but that is what the Phaser is supposed to prevent - the logging 
occurs prior to the phaser actions.

David

> I hope this clarifies the problem a bit.
>
> -JB-
>
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>>>
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -JB-
>>>>
>>>
>