Hi Vladimir, thanks for looking at this and providing feedback.
I though as well about using a handshake there. I'll try it. Thanks, Richard. -----Original Message----- From: Vladimir Ivanov <vladimir.x.iva...@oracle.com> Sent: Donnerstag, 30. Januar 2020 17:55 To: Reingruber, Richard <richard.reingru...@sap.com>; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net Subject: Re: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? 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 CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() 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 [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227 // 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).
