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
