This is an enhancement over JDK-8293980 and JDK-8309634.
The above two RFEs do not support the constant pool entries used by getstatic/putstatic/invokestatic bytecodes. The reason is these bytecodes have a side effect of initializing the target class. In some platforms, the class initialization may be triggered ONLY when the corresponding constant pool entry is resolved.
On certain platforms such as X64 and aarch64, the interpreter has "fast init checks", which can initialize the target class regardless of the state of the constant pool:
https://github.com/openjdk/jdk/blob/4b153e5e051c01ad8d0c3ff335352918c2970fe6/src/hotspot/cpu/x86/vm_version_x86.hpp#L819-L822
// x86_64 supports fast class initialization checks
static bool supports_fast_class_init_checks() {
return LP64_ONLY(true) NOT_LP64(false); // not implemented on x86_32
}
On such platforms, it should be possible to resolve the CP entries used by getstatic/putstatic/invokestatic during CDS dump time.
The above two RFEs do not support the constant pool entries used by getstatic/putstatic/invokestatic bytecodes. The reason is these bytecodes have a side effect of initializing the target class. In some platforms, the class initialization may be triggered ONLY when the corresponding constant pool entry is resolved.
On certain platforms such as X64 and aarch64, the interpreter has "fast init checks", which can initialize the target class regardless of the state of the constant pool:
https://github.com/openjdk/jdk/blob/4b153e5e051c01ad8d0c3ff335352918c2970fe6/src/hotspot/cpu/x86/vm_version_x86.hpp#L819-L822
// x86_64 supports fast class initialization checks
static bool supports_fast_class_init_checks() {
return LP64_ONLY(true) NOT_LP64(false); // not implemented on x86_32
}
On such platforms, it should be possible to resolve the CP entries used by getstatic/putstatic/invokestatic during CDS dump time.
- relates to
-
JDK-8293980 Resolve CONSTANT_FieldRef at CDS dump time
- Resolved
-
JDK-8309634 Resolve CONSTANT_MethodRef at CDS dump time
- Resolved