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

[Daniel D. Daugherty]

David,

Thanks for the fast code review!


On 6/10/14 1:12 AM, David Holmes wrote:
> 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 ??

That would be why I said "This example has not yet been spotted".
Yes, I'm being paranoid, but you knew that anyway :-)


> 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.

I'll chase this down with a native stack trace to see where
we are exactly. I don't know if I'll be able to get that done
today...

Dan


>
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>