On Tue, 2 Dec 2025 00:20:21 GMT, Vladimir Ivanov <[email protected]> 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
