RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot

[Calvin Cheung]

On Tue, 13 May 2025 07:30:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code.
> 
> The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`.
> 
> I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability.
> 
> I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes.

Looks good. I have two comments.

src/hotspot/share/classfile/classLoader.cpp line 1286:

> 1284:   const char* const class_name = ik->name()->as_C_string();
> 1285:   const char* const file_name = file_name_for_class_name(class_name,
> 1286:                                                            ik->name()->utf8_length());

Extra blank space added.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCacheSupportForCustomLoaders.java line 139:

> 137:         }
> 138:         if (c1.getModule() == c0.getModule()) {
> 139:             throw new RuntimeException("Unexpected class loader: " + c1.getClassLoader());

Should the `throw` statement be the following?

`throw new RuntimeException("Unexpected module: " + c1.getModule());`

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

PR Review: https://git.openjdk.org/jdk/pull/25199#pullrequestreview-2841072333
PR Review Comment: https://git.openjdk.org/jdk/pull/25199#discussion_r2089485297
PR Review Comment: https://git.openjdk.org/jdk/pull/25199#discussion_r2089473833