On Mon, 15 Dec 2025 17:10:24 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 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
