On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang <[email protected]> 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
