code review request for deadlock detection fix (8007476)

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Feb 26 15:54:39 PST 2013


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