On Mon, 8 Dec 2025 19:10:48 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 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/8da6ec63...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. Was is the root cause of the failure? Can it be a test 
bug?

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

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

Reply via email to