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

[Krystal Mok]

Hi Dan,

That's very nice of you. Thank you very much!

Best regards,
Kris


On Thu, May 29, 2014 at 8:52 PM, Daniel D. Daugherty <
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> 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/
>>
>> 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/
>>>
>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>
>