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

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Jun 3 12:39:46 UTC 2014


On 6/2/14 9:23 PM, serguei.spitsyn at oracle.com wrote:
> Looks good.

Thanks!

Dan


>
> Thanks,
> Serguei
>
>
> On 6/2/14 12:59 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Need a sanity check review for the JDK8u-hs backport of this fix:
>>
>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>>
>> The fix backported cleanly; JPRT is running the test right now;
>> Aurora Adhoc testing run will be started when JPRT is done...
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>



More information about the hotspot-dev mailing list