RFR: 8257831: Suspend with handshakes [v3]

[Richard Reingruber]

On Wed, 7 Apr 2021 12:04:42 GMT, Robbin Ehn <rehn at 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