VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?

Reingruber, Richard richard.reingruber at sap.com
Tue Jan 28 15:31:31 UTC 2020


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

VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get

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.


More information about the serviceability-dev mailing list