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

[David Holmes]

On 10/06/2014 2:45 PM, serguei.spitsyn at oracle.com wrote:
> It looks good to me.
> It is still hard to guarantee there are no other unexpected thread states,

I also wonder about that.

But I also question whether this is even possible:

  253     // Example 2: (This example has not yet been spotted)
  254     // "ContendingThread-1" #23 prio=5 os_prio=64 
tid=0x0000000001556000 nid=0x30 waiting on condition [0xfffffd7fbf17e000]
  255     //    java.lang.Thread.State: BLOCKED (on object monitor)

I don't see how you can be blocking on an object monitor but suddenly 
appear to be waiting on a condition ??

Looking at the comments in the bug, the Threads_lock is a mutex so it 
uses ParkEvent::park, which is PlatformEvent::park which doesn't use 
OSThreadWaitState.

David
-----


> but running for 3600 samples with no fails is convincing.
>
> Thanks,
> Serguei
>
> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>> I forgot to include a handy link to the bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>
>> Also, the new test was run for 3600 samples with the
>> -Xcomp and -XX:+DeoptimizeALot options which takes
>> about 45 minutes. With those options, the bad test
>> would fail in < 15 samples.
>>
>> The new test was also run for 3600 samples in the
>> default config which takes about 42 minutes and did
>> not fail in that config.
>>
>> Dan
>>
>>
>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Nightly testing has revealed a bug in the test that reproduces
>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>
>>> Here's the webrev URL for the minor tweak to catch yet more
>>> variation of the waiting pattern:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>
>>> Thanks to Vladimir K for reporting the test failure and for
>>> providing the right details in the bug report.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>> One more round of review after refactoring the test based on comments
>>>> from David H and Serguei.
>>>>
>>>> Here's the webrev for this round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>
>>>> Had to change the default sample size from 30 -> 15 in order to
>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>
>>>>> Here's the webrev URL for the next round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>> it is possible to get 30 runs in a row without failing.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/19/14 7:58 AM, Zhengyu Gu 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>