RFR: 8257189: Handle concurrent updates of MH.form better [v2]

[Vladimir Ivanov]

On Wed, 2 Dec 2020 14:36:16 GMT, Peter Levart <plevart at 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()?

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
        }
    }

-------------

PR: https://git.openjdk.java.net/jdk/pull/1472