Bug ID: JDK-8342429 Cache classes in loaded state

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
repo-leydenUnresolved

In JEP 483 (JDK-8315737), when the JVM starts, the boot/platform/app loaders are empty. AOT-linked classes are programmatically loaded into these loaders. One reason is to emulate the side effects of regular class loading. See discussion in

https://github.com/iklam/jdk/commit/0367e6801229197e346c961982e19516cb2b7841#commitcomment-148011489

However, this means the class of some archived heap object instances are not yet loaded when a GC happens, necessitating the work-around discussed in

https://github.com/openjdk/jdk/pull/21143#discussion_r1802291536

Also, the work spent in the loading operations will slow down start-up.

Proposal:
============
- All AOT-linked classes should be cached in (at least) the loaded state.
- The correspond states in their class loaders (java.lang.ClassLoader in Java and ClassLoaderData in C++, etc) should also be preserved.

The current plan is to do this in JDK 26 (mainline). It's quite involved. We have to first port the ArchivePackages and ArchiveProtectionDomains support from leyden to the mainline. Then we have to make (possibly) significant changes in VM start-up sequence (e.g., vmClasses::resolve_all() will be an no-op).

06-05-2025

Is there anyone working on this? Any progress?

06-05-2025