RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes

Andrew Dinn adinn at openjdk.org
Mon Sep 22 09:37:34 UTC 2025


On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java line 45:

> 43: ///   _X_ can still be triggered by normal execution of Java code in the assembly phase.
> 44: ///   This is usually the result of performing AOT optimizations for the
> 45: ///   `java.lang.invoke` package.

Suggestion:

///   At present this is usually the result of performing AOT optimizations for
///   the `java.lang.invoke` package but the set of classes which may be
///   pre-initialized via this annotation is not restricted to just that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2367293125


More information about the core-libs-dev mailing list