code review request for deadlock detection fix (8007476)

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Feb 27 06:18:33 PST 2013


Staffan,

Thanks for the review!

Runtime team, I need a review from someone...

Dan


On 2/27/13 2:30 AM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 27 feb 2013, at 00:54, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
>> Greetings,
>>
>> I have a fix to make deadlock detection a little more robust in the case
>> of being unable to find the JavaThread associated with an object lock:
>>
>>     8007476 assert(the_owner != NULL) failed: Did not find owning Java
>>             thread for lock word address
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007476
>>     https://jbs.oracle.com/bugs/browse/JDK-8007476
>>
>> Yes, I know that's not supposed to happen, but if and when it does happen,
>> it would be good to be able to diagnose the VM to try and figure out what
>> the heck happened.
>>
>> Here is the webrev URL:
>>
>>     http://cr.openjdk.java.net/~dcubed/8007476-webrev/0-hsx25/
>>
>> There is some sample output in the bug report that shows both regular
>> deadlock detection output and the proposed modified deadlock detection
>> output.
>>
>> Thanks, in advance, for any comments, suggestions or questions.
>>
>> Dan
>>
>> P.S.
>> Yes, I've included a bit of tweaking to JVM/TI code to deal with
>> invalid assertion failures that are discussed in the following bug:
>>
>>     6786879 Race in jvmti GetObjectMonitorUsage could lead to crashes
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6786879
>>     https://jbs.oracle.com/bugs/browse/JDK-6786879
>>
>> However, I haven't tried to address all the races that are discussed
>> in that bug including the race in the call to
>> JvmtiEnv::is_thread_fully_suspended() where the underlying call to
>> JavaThread::wait_for_ext_suspend_completion() can crash on lock exit.
>> Yikes, that one is nasty.



More information about the hotspot-runtime-dev mailing list