RFR 8155258: VarHandle implementation improvements

[Vladimir Ivanov]

>>
>> PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not.
>>
>
> I am guessing you mean in terms of the MH ref identity?

Yes, but I think it matters only if bytecode spinning happens (it does 
for LambdaForms). What matters for the JVM is the method MH points to 
(through MH.form.vmentry.vmtarget). So, if a method handle always points 
to the same method, a race when publishing the handle should be benign.

Best regards,
Vladimir Ivanov
>
>
>> In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles).
>>
>> The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired.
>>
>> I can't say for sure it's not the case for VarHandles as well.
>>
>
> Ok, i will take a closer look at the existing caches (i did look at those for inspiration) and follow up. I might need to synchronise the update.
>
> FWIW there are also cases in MethodHandleImpl where MHs are cached without synchronization, perhaps such constraints don’t matter in these cases?
>
> Paul.
>