On Mon, 8 Dec 2025 17:49:41 GMT, Jorn Vernee <[email protected]> wrote:
>> 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 15 additional >> commits since the last revision: >> >> - 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 >> - Redundant change >> - Merge branch 'master' of https://github.com/openjdk/jdk into >> fix/vh-adapt-cache >> - ... and 5 more: https://git.openjdk.org/jdk/compare/50bcb546...eebb8ff7 > > src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114: > >> 112: // but checking the signature type of MH mostly works >> 113: return MethodHandle.isReachableFrom(vform.getMethodType(0), cl) >> 114: && target.isReachableFrom(cl); > > Right... one of the filters may also keep a class loader alive. But to check > them, we'd have to eagerly instantiate all of them as well. > > FWIW, I don't think this is an issue we can just ignore. If a filter keeps a > class loader alive, we'd still have a problem. > > Maybe it's possible to collect all the types involved from the filter when > creating an IndirectVarHandle instead, and save those in a separate list for > this check. I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599683049
