RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3]

[Dan Heidinga]

On Fri, 22 Aug 2025 17:24:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
>> 
>> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
>> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
>> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run

src/hotspot/share/cds/aotOopChecker.cpp line 52:

> 50: // Make sure we are not caching objects with assumptions that can be violated in
> 51: // the production run.
> 52: void AOTOopChecker::check(oop obj) {

Should this also return a `bool` to indicate if the oop failed the check?  It would make it easier to bail out in the caller if the oop was bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294377983