code review request for deadlock detection fix (8007476)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Feb 27 06:59:42 PST 2013
Thanks for the review!
On 2/27/13 7:52 AM, Karen Kinnear wrote:
> Code looks good. I did not study the details (again) for the monitor owner, but
> my memory is that there are other cases in which the monitor owner can be
> temporarily null, so this is will help there also.
> On Feb 26, 2013, at 6:54 PM, Daniel D. Daugherty wrote:
>> 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
>> 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:
>> There is some sample output in the bug report that shows both regular
>> deadlock detection output and the proposed modified deadlock detection
>> Thanks, in advance, for any comments, suggestions or questions.
>> 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
>> 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