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

Ioi Lam iklam at openjdk.org
Fri Aug 22 18:41:54 UTC 2025


On Fri, 22 Aug 2025 14:10:02 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The assembly phase shouldn't execute any user Java code. If that happens, it can result in many undesirable side effects. Loading user native library will be just one example.
>> 
>> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.
>> 
>> Maybe I should do that in a separate RFE?
>
>> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.
> 
> That would be a good check.
> 
> Do we still assembly-time initialize Enums?  I thought in earlier implementations we had initialized all enum classes but I'm having trouble finding the code now.  If we do, the new "no user class initialized" check may fail on Enums

With JEP 483, if we find a cached instance of an enum class, this class is automatically marked as aot-initialized. Since we never execute user code (I filed [JDK-8366020](https://bugs.openjdk.org/browse/JDK-8366020) to check this), we won't have any cached instances of user enum classes. One risky area is the handling of enums in MethodTypes, so I added a added a test case to check that user enum types used by a Lambda expression are not initialized in the assembly phase.  See https://github.com/openjdk/jdk/pull/26375/commits/f12ad484639b98a2714d27a7a99ec9a48193656b

I also updated the comments in `HeapShared` and `CDSEnumKlass` about how enums are handled (JEP 483 vs legacy). See https://github.com/openjdk/jdk/pull/26375/commits/62014d4ff1dec5181362ca0c3eb0d89facf10283

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

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


More information about the hotspot-dev mailing list