RFR: 8231289: Disentangle JvmtiRawMonitor from ObjectMonitor and clean it up

David Holmes david.holmes at oracle.com
Fri Oct 4 03:58:04 UTC 2019

Okay, to allow for me to make forward progress here I've decided to 
follow the "principle of least brokenness" ;-)

Recap: Because of JVMTI event callbacks it is possible for a thread to 
set its current pending monitor as a JvmtiRawMonitor when it was already 
set for an ObjectMonitor. This is broken in at least two ways:
- when the raw monitor use completes the pending monitor is set to NULL, 
not restored to the ObjectMonitor
- whilst the raw monitor is seen as the pending monitor the 
ObjectMonitor is not considered by the deadlock detection logic

Ignoring what I'm currently doing with jvmtiRawMonitor, I do not know 
how to fix the above brokenness and it is out of scope for what I am 
trying to do.

So what I propose is to make things no more broken than they are now, 
and actually improve things a little:
- the pending JvmtiRawMonitor is given preference over the ObjectMonitor 
in the deadlock detection code (this emulates current situation of the 
raw monitor overwriting the pending ObjectMonitor)
- we no longer lose the fact we were also pending on an ObjectMonitor
- the stack printing code in the deadlock detector prints information 
about both the raw monitor and the ObjectMonitor

Updated webrev:


The only change is threadService.cpp


More information about the hotspot-runtime-dev mailing list