Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8238585

JvmtiEventControllerPrivate::enter_interp_only_mode() should not make compiled methods on stack not_entrant



    • Enhancement
    • Resolution: Fixed
    • P4
    • 15
    • 15
    • hotspot
    • b27


      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

      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).


        Issue Links



              rrich Richard Reingruber
              rrich Richard Reingruber
              0 Vote for this issue
              2 Start watching this issue