We have two classes with an @AOTRuntimeSetup method whose sole purpose is to register an Access handler with SharedSecrets:
https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/java.base/share/classes/java/lang/ref/Reference.java#L293-L299
https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#L1538-L1543
Currently, the reason for using @AOTRuntimeSetup here is both Reference and MethodHandleImpl are AOT-initialized, so their <clinit> are not executed in the production run. However, currently SharedSecrets does not have @AOTSafeClassInitializer, so its stored in the AOT cache in "uninitialized" state. Therefore, we need the runtimeSetup() methods to re-registered the access handlers.
This can be simplified by adding @AOTSafeClassInitializer to SharedSecrets, so all the access handlers registered during the AOT assembly phase will remain valid for the production run.
We can then remove the @AOTRuntimeSetup from Reference and MethodHandleImpl
https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/java.base/share/classes/java/lang/ref/Reference.java#L293-L299
https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#L1538-L1543
Currently, the reason for using @AOTRuntimeSetup here is both Reference and MethodHandleImpl are AOT-initialized, so their <clinit> are not executed in the production run. However, currently SharedSecrets does not have @AOTSafeClassInitializer, so its stored in the AOT cache in "uninitialized" state. Therefore, we need the runtimeSetup() methods to re-registered the access handlers.
This can be simplified by adding @AOTSafeClassInitializer to SharedSecrets, so all the access handlers registered during the AOT assembly phase will remain valid for the production run.
We can then remove the @AOTRuntimeSetup from Reference and MethodHandleImpl