RFR: 8284579: Improve VarHandle checks for interpreter [v2]

[Claes Redestad]

On Mon, 11 Apr 2022 09:57:42 GMT, Claes Redestad <redestad at 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