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

[Chen Liang]

On Mon, 15 Dec 2025 17:10:24 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/faea2335...f9d808c1

Since I just noticed the actual cause of the failure of caching is that AD is created per name+type combination, I have created a benchmark case for that instead of reusing the existing exact ones:


Benchmark                                 Mode  Cnt  Score   Error  Units
VarHandleTypeMismatch.exactInvocation     avgt   30  0.396 ± 0.009  ns/op
VarHandleTypeMismatch.genericInvocation   avgt   30  0.375 ± 0.009  ns/op
VarHandleTypeMismatch.pollutedInvocation  avgt   30  8.281 ± 0.222  ns/op

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

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