RFR 8155258: VarHandle implementation improvements
paul.sandoz at oracle.com
Wed May 4 16:47:56 UTC 2016
> On 4 May 2016, at 09:19, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> Looks good.
> I'm fine with pushing it directly into jdk9/dev, since the change just relaxes the assert and the risk of a merge conflict is very small.
> Best regards,
> 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?
> 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?
More information about the hotspot-dev