When -XX:+ArchiveInvokeDynamic is enabled, some classes in java.base may have a pre-resolved invokehandle or invokedynamic constant pool entry whose class (a LambdaForm or Lambda Proxy) is not yet loaded. This can happen between the window of
ClassPrelinker::init_javabase_preloaded_classes(CHECK_JNI_ERR);
and
initialize_jsr292_core_classes(CHECK_JNI_ERR);
in https://github.com/openjdk/leyden/blob/cddf20a5baee9b55805700547d5148560e4d7f1f/src/hotspot/share/runtime/threads.cpp#L736-L747
=======================
The proper fix would be to do this first:
- Load all the preloaded classes in java.base (including all archived LambdaForm classes, and the Lambda Proxy classes that belong to java.base)
- Of the above classes, initialize all the ones that were dump-time initialized
The above should be done very quickly with just a few thousand bytecodes.
We then start the compiler and replay the training data -- which will cause some of the methods in the above classes to be eagerly compiled (either with the JIT or loaded from the AOT cache).
ClassPrelinker::init_javabase_preloaded_classes(CHECK_JNI_ERR);
and
initialize_jsr292_core_classes(CHECK_JNI_ERR);
in https://github.com/openjdk/leyden/blob/cddf20a5baee9b55805700547d5148560e4d7f1f/src/hotspot/share/runtime/threads.cpp#L736-L747
=======================
The proper fix would be to do this first:
- Load all the preloaded classes in java.base (including all archived LambdaForm classes, and the Lambda Proxy classes that belong to java.base)
- Of the above classes, initialize all the ones that were dump-time initialized
The above should be done very quickly with just a few thousand bytecodes.
We then start the compiler and replay the training data -- which will cause some of the methods in the above classes to be eagerly compiled (either with the JIT or loaded from the AOT cache).