RFR: 8317269: Store old classes in linked state in AOT cache [v4]
Matias Saavedra Silva
matsaave at openjdk.org
Fri Aug 29 17:59:46 UTC 2025
On Thu, 28 Aug 2025 05:03:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this:
>>
>>
>> class X {
>> A getA() { return new B(); } // Verifier requires B to be a subtype of A.
>> }
>>
>>
>> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if
>>
>> - `A` fails verification
>> - `B` is a signed class, which is always excluded from the AOT cache
>>
>> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run.
>>
>> Notes for reviewers:
>>
>> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details.
>> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`.
>> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`.
>> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`.
>
> Ioi Lam 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:
>
> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache
> - @coleenp comments
> - More bug fixes from JCK testing
> - Fixed bugs found in JCK testing
> - 8317269: Store old classes in linked state in AOT cache
Looks good, thanks for this! There are some typos in the comments and we had an offline discussion about the lambda. Once those are fixed I can approve
src/hotspot/share/cds/cdsConfig.cpp line 939:
> 937: // of the production run. This means that if a class was successfully verified
> 938: // in the assembly phase, all of the verifier's assignability checks will remain
> 939: // valid in the production run, so we don't need to verify aot-lined classes again.
Type: aot-lined -> aot-linked
src/hotspot/share/cds/dumpTimeClassInfo.cpp line 94:
> 92: if (log_is_enabled(Trace, aot, verification)) {
> 93: ResourceMark rm;
> 94: log_trace(aot, verification)("add old verification dependency: %s: %s must be also be archived",
Should this comment be "added old..."?
src/hotspot/share/classfile/systemDictionaryShared.cpp line 241:
> 239: }
> 240:
> 241: // This is a table of classes that need to be check for exclusion.
Typo: check -> checked
src/hotspot/share/classfile/systemDictionaryShared.cpp line 312:
> 310: ResourceMark rm;
> 311:
> 312: // This will recursive find ik and all of its exclusion dependencies that have not yet been checked.
Typo: recursively
-------------
Changes requested by matsaave (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3169379131
PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310625223
PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310647700
PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310670483
PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310680295
More information about the hotspot-dev
mailing list