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

[Zhengyu Gu]

Good to me.

Thanks Dan,

-Zhengyu

On 5/29/2014 10: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
>>>
>>
>>
>>
>