JvmtiEventControllerPrivate::enter_interp_only_mode() switches execution mode for one JavaThread to
interpreter only execution. To do so it executes the vm operation VM_EnterInterpOnlyMode which makes
all compiled java methods on stack not_entrant. This is not necessary. It is sufficient to
deoptimize the compiled frames, i.e. patch their return address with the address of the deopt
handler. It might be for historical reasons that the compiled methods are made not_entrant. If I
remember correctly, deoptimizing a frame meant overriding the corresponding compiled method with a
slide of nops leading to the deopt handler, but this changed long ago.

That clean-up is the main goal of the item.

The following enhancement is a sub-goal: replace the vm operation VM_EnterInterpOnlyMode with a
direct handshake. The safepoint for VM_EnterInterpOnlyMode synchronizes accesses of
JvmtiThreadState::_cur_stack_depth and JavaThread::_interp_only_mode, but the weaker synchronization
of a direct handshake is sufficient, because other accesses of _cur_stack_depth are either at
safepoints or directly by the associated thread.

JavaThread::_interp_only_mode is a little more difficult, because it is set to 0 by other threads
without synchronization with the owner thread (see JvmtiThreadState::leave_interp_only_mode() and
note that the value is also read in the assertion before). But at least the accesses from other
threads are well synchronized using JvmtiThreadState_lock. E.g. let Thread A1 turn on interp. only
mode for target thread T. A direct handshake is sufficient to sync. this action with execution of
T. If another thread A2 turns interp. only mode off for T, then this is synchronized with A1's
action, because both acquired JvmtiThreadState_lock. Only T's execution is not in sync with A2's
action, but that's ok: leaving interp. only mode can be asynchronous, whereas entering has to be
synchronous.

Note that VM_EnterInterpOnlyMode can be executed at a safepoint as nested vm operation. This is
currently not supported for handshakes. As a workaround the do_thread() method of the
HandshakeClosure can be called directly at safepoints (w/o handshake, see also JDK-8239084).