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

[serguei.spitsyn at oracle.com]

Hi Dan,

The fix itself looks good.

The test deserves a refactoring as the main method is too big.
Would it be possible to convert some of the blocks of the while loop 
into methods?
Even the try block (variant: the while loop) is a good candidate to be a 
separate method.
Also the definitions of the patterns can be moved out of the main and 
made static final fields.

Thanks,
Serguei


On 5/22/14 9: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
>>
>