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

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri May 30 14:26:39 UTC 2014


On 5/30/14 12:07 AM, Krystal Mok wrote:
> Hi Dan,
>
> That's very nice of you. Thank you very much!

No problem. Happy to share the blame if we get this wrong again! :-O

Just for the record, any problems with the test are mine!
Normally I would write a test like this using shell (and the
first version attached to the bug is implemented that way),
but we're trying very hard to not to add any more shell tests
to the repository.

Dan


>
> Best regards,
> Kris
>
>
> On Thu, May 29, 2014 at 8:52 PM, Daniel D. Daugherty 
> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> wrote:
>
>     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
>>
>>
>>
>>
>>
>>
>
>



More information about the hotspot-dev mailing list