code review request for deadlock detection fix (8007476)

[Staffan Larsen]

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.