Currently AOTClassInitializer::can_archive_initialized_mirror has a hard-coded list that affects the AOT initialization status of certain classes in the JDK.

This marking should probably be done in the Java source code, where it can be reasoned about more readily.

An annotation @AOTInitialize (private to the JDK) would probably do the trick.

A similar annotation @RuntimeInitialize might be useful to specify JDK classes which have been determined must NEVER be given the aot-init treatment. This might feed into useful error checks.

In the same vein, for classes which need to factor apart separate AOT and runtime initialization effects, a @RuntimeSetupRequired annotation may be useful to mark classes which demand special processing during startup. These classes may include Class itself, the internal Unsafe, and ConcurrentHashMap. Currently they all have a private method called runtimeSetup which must be called if the VM detects that the class was AOT-initialized. This seems to be a workable pattern, but to make it less magic it needs to be more clearly marked.

In a complementary direction, there are also magic methods with names like createArchivedObjects and and resetArchivedStates which manage data just before dumping (in the assembly phase). It seems like these fixup methods, both the ones that execute during the assembly phase to finalize the object graph, and those that execute during the startup of the production run, should be clearly related to each other. Perhaps an annotation or two would be used for all of them. Currently the VM C++ code is hard-coded to look for BOTH a particular class AND the magic name.

As a related move, the pattern matching that checks for valid bootstrap specifiers should probably be moved into the JDK, somehow. At a minimum, an annotation like @AOTBootstrapMethod could be attached to those few BSMs in the JDK which are safe to AOT-link.