On Wed, 7 Apr 2021 12:04:42 GMT, Robbin Ehn <r...@openjdk.org> wrote:
> 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. > You mean the JVMTI agent suspends the current thread and then observes that the thread state first has the attribute JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER and in a later call it does not have it anymore (~ThreadBlockInVM doesn't check for suspend)? Yes that's problematic too. With the new code we could remain suspended with JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER. I think the OM would not be reported as owned monitor but another thread could not lock it. > If you agree that the issue is preexisting I prefer handling that outside > scope of this. I'm ok with that. A simple solution could then be making use of ThreadBlockInVM. When returning from EnterI in L413 we would set a rollback function in the HandshakeState which can be called in HandshakeState::suspend_in_handshake() to exit the OM. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191
