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

[Daniel D. Daugherty]

Thanks for the review!

BTW, I'm listing you, Zhengyu and me on the 'Contributed-by' line
since the three of us had a hand in various versions and parts of
this fix. :-)

Dan


On 5/29/14 7:39 PM, Krystal Mok wrote:
> Hi Dan,
>
> The new fix looks good to me (not a Reviewer). Thumbs up!
>
> Thanks,
> Kris
>
>
> On Thu, May 29, 2014 at 7:49 AM, Daniel D. Daugherty 
> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> 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/
>     <http://cr.openjdk.java.net/%7Edcubed/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/ <http://cr.openjdk.java.net/%7Edcubed/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/
>             <http://cr.openjdk.java.net/%7Ezgu/8036823/webrev.00/>
>
>
>             Thanks,
>
>             -Zhengyu
>
>
>
>
>
>