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

[Chen Liang]

On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH.  Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`)
>
> 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 eight additional commits since the last revision:
> 
>  - Rollback getAndAdd for now
>  - Redundant change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Stage
>  - Review tweaks
>  - Tweak VH usage in some classes
>  - Logical fallacy
>  - 8160821

After consulting with @iwanowww, I realized the non-constant status cannot be determined, that the C2 compiled method can even transition from 0 to 1, so I am simplifying this code to only handle the constant case. It seems the getAndAdd IR test no longer fails with this change, and I removed a lot of other redundant changes.

I updated the VarHandleExact benchmark added by @JornVernee, and added a case of dropping return values by changing access mode to `getAndAdd` consistently. Now they have the following performance numbers:

Benchmark                                        Mode  Cnt  Score   Error  Units
VarHandleExact.exact_exactInvocation             avgt   30  3.843 ± 0.062  ns/op
VarHandleExact.generic_exactInvocation           avgt   30  3.797 ± 0.049  ns/op
VarHandleExact.generic_genericInvocation         avgt   30  3.757 ± 0.034  ns/op
VarHandleExact.generic_returnDroppingInvocation  avgt   30  3.754 ± 0.026  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3604377750