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

[Vladimir Ivanov]

On Wed, 2 Dec 2020 15:30:07 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
>>         }
>>     }
>
> Ah, I see. Customization only happens for non-constant MHs. Everything is fine then. Sorry for confusion.

Thanks a lot for such a thorough review, Peter!

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

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