RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3]

[Chen Liang]

On Tue, 2 Dec 2025 00:20:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak VH usage in some classes
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033:
> 
>> 2031: 
>> 2032:         @ForceInline
>> 2033:         MethodHandle adaptedMethodHandle(VarHandle vh) {
> 
> Can you elaborate, please, how this method is intended to behave?

When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before.

> test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78:
> 
>> 76:     @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE)
>> 77:     public static void addB() {
>> 78:         var _ = (byte) B.getAndAdd(b2);
> 
>> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. 
> 
> It has performance implications for user code, doesn't it?

The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects  `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations.

The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579218324
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579221253