RFR: 8350550: Preload classes from AOT cache during VM bootstrap

[Dan Heidinga]

On Mon, 18 Aug 2025 20:33:45 GMT, Dan Heidinga <heidinga 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.
>
> src/java.base/share/classes/java/net/URL.java line 1768:
> 
>> 1766: 
>> 1767:     @AOTRuntimeSetup
>> 1768:     private static void runtimeSetup() {
> 
> Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto.
> 
> Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run?

Are there limits on the types of URLs we allow in the archived heap?  ie: only file or jar?

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

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