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
