VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Jan 30 16:55:25 UTC 2020

Hi Richard,

> I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this
> seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and
> let them return to their deopt handler. Or what would be the reason to make the compiled methods
> not_entrant?
> VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get
> marked.
> Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant.
> Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a
> compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod
> not_entrant meant overriding its code with a slide of nops that led to the deopt handler.
> I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on
> stack. I've done this locally and tested the change without issues.

I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is 
performed on per-thread basis [1], it looks like per-frame 
deoptimization (instead of per-nmethod) should be enough to do the job.

So, from JIT-compiler perspective, your suggestion to use 
Deoptimization::deoptimize() instead of 
sounds good.

PS: also, it looks like handshakes become a perfect fit for 
VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod 
basis, there's no need to trigger global safepoint.

Best regards,
Vladimir Ivanov


     // If running in fullspeed mode, single stepping is implemented
     // as follows: first, the interpreter does not dispatch to
     // compiled code for threads that have single stepping enabled;
     // second, we deoptimize all methods on the thread's stack when
     // interpreted-only mode is enabled the first time for a given
     // thread (nothing to do if no Java frames yet).

More information about the serviceability-dev mailing list