On Thu, 18 Jun 2026 13:07:09 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 five additional >> commits since the last revision: >> >> - Fix missing trusted final field query >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into >> fix/lw-strict-static-vh >> - Restrict write access for IMPL_LOOKUP VH on strict final >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into >> fix/lw-strict-static-vh >> - Missing strict static validation for VarHandle > > src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java > line 116: > >> 114: return target.getMethodHandle(accessMode); >> 115: >> 116: return super.getMethodHandleUncached(accessMode); > > `target.getMethodHandle` goes to the target, but > `super.getMethodHandleUncached` goes to our `vform`, which is the target's > `vform`. What's the difference? (besides the lack of caching in the targets > `methodHandleTable` in the latter case) Both will end up returning the same > method handle right? After looking with a debugger, it seems that we're safe from skipping the init check when calling `toMethodHandle` because the `get` of the target will end up calling `onStaticFieldAccess` for the original VarHandle, which is this one, so we end up doing the init check. Looks like the old code was doing a redundant `ensureInitialized` call in that case. I'm still a little puzzled about why the update to `methodHandleTable` in `initialize` is needed. It looks like this prevents two copies of identical tables floating around (one in the `target`, and one in this VH). It would be great if you could put a comment on `this.methodHandleTable = target.methodHandleTable;` about that. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2550#discussion_r3436269930
