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

[Daniel D. Daugherty]

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
>