RFR: 8368182: AOT cache creation fails with class defined by JNI

David Holmes dholmes at openjdk.org
Mon Sep 22 07:42:31 UTC 2025


On Sun, 21 Sep 2025 20:00:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
> 
> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
> 
> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
> 
> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

So where were these JNI defined classes originating from when you saw the failures?

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

> 1194:   if (src == nullptr) {
> 1195:     if (loader == nullptr) {
> 1196:       // JFR classes

What was this referring to? I traced this back to "8186842: Use Java class loaders for creating the CDS archive" but no mention of any JFR classes was made. FWIW I can't see any use of JNI DefineClass in the JDK code, so this change would only affect end-user code.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JNIDefineClass.java line 128:

> 126: }
> 127: 
> 128: // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DefineClass() with a null code source,

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JNIDefineClass.java line 134:

> 132: }
> 133: 
> 134: // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DefineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

test/hotspot/jtreg/runtime/cds/appcds/aotCache/libJNIDefineClassApp.c line 34:

> 32:     jclass returnValue = (*env)->DefineClass(env, classNameChar, classLoader, arrayContent, bytecodeLength);
> 33:     (*env)->ReleaseByteArrayElements(env, bytecode, arrayContent, JNI_ABORT);
> 34:     (*env)->ReleaseStringUTFChars(env, className, classNameChar);

Does this pass `-Xcheck:jni`? ie. do you need to check for exceptions in the above sequence.

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

PR Review: https://git.openjdk.org/jdk/pull/27412#pullrequestreview-3250774051
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366846765
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366844318
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366844859
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366843584


More information about the hotspot-runtime-dev mailing list