On Wed, 2 Dec 2020 15:24:47 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> Would it make a difference if MH.form was not final and each read access to >> it was done via appropriate Unsafe.getReferenceXXX()? > >> Would it make a difference if MH.form was not final and each read access to >> it was done via appropriate Unsafe.getReferenceXXX()? > > It would break inlining through MH calls. JITs trust `MH.form` and > aggressively inline through it. > >>I was just concerned that optimization in one part (less resources consumed >>updating the form) would increase the probability of JIT-ed code using the >>old form indefinitely - therefore causing regression in top performance. > > That's expected and happens in practice. It was a deliberate choice to avoid > invalidating existing code and triggering recompilations while sacrificing > some performance. > > But if we focus on MH customization, there's no inlining happening (or > possible): customization is performed on a non-constant (in JIT sense) MH > instance which is about to be invoked through `MH.invoke()/invokeExact()`. > So, subsequent calls through invoker on the same (non-constant) MH instance > should see updated `MH.form` value (customized LambdaForm): > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L598 > @ForceInline > /*non-public*/ > static void checkCustomized(MethodHandle mh) { > if (MethodHandleImpl.isCompileConstant(mh)) { > return; // no need to customize a MH when the instance is known > to JIT > } > if (mh.form.customized == null) { // fast approximate check that the > underlying form is already customized > maybeCustomize(mh); // marked w/ @DontInline > } > } Ah, I see. Customization only happens for non-constant MHs. Everything is fine then. Sorry for confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472
