RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead of 'waiting to lock'

[Daniel D. Daugherty]

Looks like there were two e-mails threads along these lines:

     Subject: Are there any liveness issues about thread scheduling in 
the JVM?
     Subject: Multiple Java threads seem to have locked the same object 
monitor
              from the thread dumps

The first thread started on 2012.07.10 and ended on 2012.07.16.
The second thread started on 2012.07.12 and ended the same day.

Both threads ended when the topic evolved to reproducers.

Dan


On 5/19/14 8:11 PM, David Holmes wrote:
> Kris,
>
> This does indeed appear to be the same issue. I don't recall why that 
> discussion in July 2012 just came to a halt. :(
>
> Sorry about that.
>
> David
>
> On 20/05/2014 8:00 AM, Krystal Mok wrote:
>> Hi Zhengyu,
>>
>> I just glanced over your changes, and the description looks like 
>> something
>> I've seen in the past:
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004106.html 
>>
>>
>> Could you please take a look at the old discussion thread and see if
>> they're the same thing?
>>
>> Thanks,
>> Kris
>>
>>
>> On Mon, May 19, 2014 at 6:58 AM, Zhengyu Gu <zhengyu.gu at oracle.com> 
>> wrote:
>>
>>> This is a simple fix for incorrect lock state.
>>>
>>> The timing on setting thread's pending monitor can result stack 
>>> trace dump
>>> reporting incorrect lock state. The solution is to check the monitor's
>>> owner, if the owner is other than the current thread, then the 
>>> monitor, is
>>> or is in process of being, set the pending monitor of current thread.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>