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

[Chen Liang]

On Wed, 10 Dec 2025 19:48:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Bugs and verify loader leak
>>  - Try to avoid loader leak
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>>  - Test from Jorn
>>  - Copyright years
>>  - Fix problem identified by Jorn
>>  - Rollback getAndAdd for now
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/f510a486...d734e8a6
>
> make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132:
> 
>> 130:     // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails
>> 131:     // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and
>> 132:     // testArrayAtomicThenAtomicAtUnknownIndices works
> 
> It doesn't look right. What is the root cause of the failure? Can it be a test bug?

I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort.

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

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