On Fri, 25 Apr 2025 20:54:21 GMT, John R Rose <jr...@openjdk.org> wrote:
>> Aleksey Shipilev 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 four additional >> commits since the last revision: >> >> - Minor touchup >> - Merge branch 'master' into JDK-8342283-cds-many-classes >> - Adjust TEST.groups >> - Fix > > src/java.base/share/classes/java/lang/ClassLoader.java line 2590: > >> 2588: * @implNote This is done while the JVM is running in >> single-threaded mode, >> 2589: * and at the very end of Java bytecode execution. We know that no >> more classes >> 2590: * will be loaded and none of the fields modified by this method >> will be used again. > > There is a tiny technical debt here. If future AOT code generation uses a > future aggressive constant folding of object fields (cf. > `TrustFinalNonStaticFields`) and a constant CL reference ends up in optimized > code and there is a constant-folded reference (and.. and…) it is remotely > possible that the old value of the field will get wrongly embedded in AOT > code. > > If we arrange AOT code generation to occur after all of these fixups (in Java > code) are done, then the problem will not occur. It's a delicate set of > invariants. Your expanded comment is a good start at calling them out, but > this is a long string we are pulling on. (I borrowed this comment from the initial @iklam's PR, so I need to credit him as contributor.) Yes, CDS does awkward state manipulations at dump time. Resetting the states of final/`@Stable` objects can run into issues that you described. I think this is one of the reasons why Leyden generates AOT code with `-XX:-FoldStableValues`: https://github.com/openjdk/leyden/blob/885096a8b3194371cde6b96ce5554d89f99618d7/src/hotspot/share/code/aotCodeCache.cpp#L162 I would guess we need to do the same with `TrustFinalNonStaticFields`. The awkward part of current `trust_final_non_static_fields()` code is that it implicitly trusts things in `java/lang`, even with `-TrustFinalNonStaticFields`. That sounds like something we need to rectify for Leyden AOT code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2063277934