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

[David Holmes]

Hi Dan,

Functional changes look good.

For the test I thought the preferred approach these days was to use the 
testlibrary utilities to launch the test in another VM and also launch 
the tool. That way the test isn't restricted to needs_jdk.

Cheers,
David

On 23/05/2014 2: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
>>
>