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.
