-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
Either hide constantPoolOop or expose it as a field of jdk_internal_reflect_ConstantPool but we don't need this filtering mechanism for any reason.
The reason that constantPoolOop is the java.lang.Class instance (mirror) and not a ConstantPool* is because the latter is metadata managed by storage in the VM so would need special handling if there were pointers to it in the Java heap. The reason for the special handling is because class redefinition could delete the ConstantPool if old methods were no longer running. Because of constant pool merging for class redefinition, the InstanceKlass->constant pool pointer will maintain the validity of indices that the Java code might retrieve from jdk_internal_reflect_ConstantPool.
The reason that constantPoolOop is the java.lang.Class instance (mirror) and not a ConstantPool* is because the latter is metadata managed by storage in the VM so would need special handling if there were pointers to it in the Java heap. The reason for the special handling is because class redefinition could delete the ConstantPool if old methods were no longer running. Because of constant pool merging for class redefinition, the InstanceKlass->constant pool pointer will maintain the validity of indices that the Java code might retrieve from jdk_internal_reflect_ConstantPool.
- relates to
-
JDK-8365885 Clean up constant pool reflection native code
-
- Open
-