On Mon, 11 Apr 2022 09:57:42 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 719: >> >>> 717: // >>> MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>); >>> 718: // } else { >>> 719: // MethodHandle mh = >>> handle.getMethodHandle(ad.mode); >> >> The `direct`‑ness check can be hoisted into an enclosing `if` statement: >> Suggestion: >> >> // if (direct) { >> // if (handle.vform.methodType_table[ad.type] == >> ad.symbolicMethodTypeErased) { >> // >> MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>); >> // return; >> // } else if (handle.vform.getMethodType_V(ad.type) >> == ad.symbolicMethodTypeErased) { >> // >> MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>); >> // return; >> // } >> // } >> // MethodHandle mh = handle.getMethodHandle(ad.mode); >> >> >> Also, any reason `GUARD_METHOD_TEMPLATE_V` uses `LINK_TO_STATIC_ARGS` >> instead of `LINK_TO_STATIC_ARGS_V`? > >> How would the performance change if the `isDirect` and >> `checkExactAccessMode` merger was reverted? > > Add around 15-20ns/op for these micros. Restructuring so that we only check `direct` once sounds reasonable at face value but would be a lot of churn for little gain (even in the interpreter testing a local boolean field is fast, and JITs will optimize this well). The `LINK_TO_STATIC_ARGS_V` in the code generator seems like a remnant from an earlier iteration of this code. The `vform.getMemberName_V` method the code generator would emit a call to doesn't even exist. This should probably be cleaned up, separately. @PaulSandoz, WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/8160