On Wed, 7 Apr 2021 11:50:09 GMT, Robbin Ehn <r...@openjdk.org> wrote:
>> src/hotspot/share/runtime/objectMonitor.cpp line 428: >> >>> 426: } else { >>> 427: // Only exit path from for loop >>> 428: SafepointMechanism::process_if_requested(current); >> >> I think the current thread can suspend here in L428. This seems problematic >> as entering OM has been started but not completed. >> >> - The current thread is set as owner in ObjectMonitor::_owner >> - The thread state will still be JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER >> because of the JavaThreadBlockedOnMonitorEnterState in L389. >> - Thread::_current_pending_monitor has not been reset to NULL. > > Yes, I think you are correct. I'll look over it. Today the ThreadBlockInVM tbivm(current); is inside scope of JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);. So this can happen today also. If you are context switch just before current->set_current_pending_monitor(NULL);. Someone suspends you and look at those states. If you agree that the issue is preexisting I prefer handling that outside scope of this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191