On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam <[email protected]> wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be >> (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache >> in an already initialized state. This means that all the static fields in >> this class will be immediately available upon JVM bootstrap when the AOT >> cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More >> classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must >> be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is >> initialized (see JVMS 5.5. Initialization, step 7; also C++ function >> `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to >> `AOTClassInitializer::check_aot_annotations()`. The previous check in >> `ClassFileParser` was not executed because the class is loaded in the AOT >> training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns >> `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not >> sure if we need both. Please see the javadoc in `@AOTInitialize` to see the >> difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit > since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make > test JTREG=AOT_JDK=onestep ..."
> This annotation is awfully similar to @AOTSafeAnnotation, and I am not sure > if we need both Maybe we do want both. @AOTSafeAnnotation is weaker than @AOTInitialize because the former only initializes classes optionally when we find it is needed. If we only had @AOTInitialize then we would lose that optionality. It may not make much difference now -- we probably only have these annotations for JDK classes that would need to be class-inited whatever the training regime. However, as we expand use of the annotation might we risk initing classes and including their state in the archive without necessarily seeing any benefit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3297343820
