JDK-8336804 : Drop callback from class to its signers with ref kind JVMTI_HEAP_REFERENCE_SIGNERS
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-07-19
  • Updated: 2024-11-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8334772 - Change Class::signers to an explicit field
Relates :  
JDK-8035288 - Make jvmti report references to signers as part of java/lang/Class optional
Relates :  
JDK-8003551 - Move Signers out to the JDK
Description
The JVM TI heap functions (FollowReferences et. al.) invoke a callback for references from a Class object to its signers (array) when the Class has signers. This is carry over from the legacy JVMPI API and JVMPI_GC_CLASS_DUMP record, and maybe necessary at the time because the reference to the signers was maintained in the VM rather than as an explicit field in java.lang.Class.

JDK-8334772 has moved signers from injected field to an explicit field. JVMTI agents using the heap functions will now get a callback for the reference from a class object to its signers array (with ref kind JVMTI_HEAP_REFERENCE_FIELD).

It's time to drop invoking a callback with ref kind JVMTI_HEAP_REFERENCE_SIGNERS. This should only require some small updates to the JVMTI spec. Note that the JVMTI_HEAP_REFERENCE_SIGNERS field needs to be maintained for source compatibility reasons, it's just that a callback will never be invoked with this ref kind.
Comments
I'm not sure I understand the rationale of the RFE. After some history research, I suppose main goal here is reduction of Class instance size. Does it mean we are going to get rid of the Class.signers field? About RFE itself - as already mentioned, instance field references are not reported for Class objects, so statement in the description that agents get references to signers as JVMTI_HEAP_REFERENCE_FIELD is not correct. So it looks like if we drop invoking callback with JVMTI_HEAP_REFERENCE_SIGNERS, we need to obsolete JVMTI_HEAP_REFERENCE_SIGNERS kind (we cannot make it optional because RI must implement optional functionality)
11-10-2024
I have reset the title back to focus on JVMTI_HEAP_REFERENCE_SIGNERS. That's the legacy reference that does not make sense to report via a callback. I don't think JVMTI_HEAP_REFERENCE_CLASS_LOADER should be changed, it's much more likely that something is dependent on that.
11-10-2024
It was expected to be a small low-risk JVMTI spec update (add notes to VMTI_HEAP_REFERENCE_CLASS_LOADER/JVMTI_HEAP_REFERENCE_SIGNERS descriptions that the references may be reported as JVMTI_HEAP_REFERENCE_FIELD). But it appears to be more complicated. The spec says: - Instance objects report references to each non-primitive instance fields (including inherited fields). - Instance objects report a reference to the object type (class). - Classes report a reference to the superclass and directly implemented/extended interfaces. - Classes report a reference to the class loader, protection domain, signers, and resolved entries in the constant pool. - Classes report a reference to each directly declared non-primitive static field. FollowReferences implementation does not consider Class objects as "instance objects" and does not report instance fields and class (object type). So the question if we want to report all instance fields for Class objects? I don't think it's worth it and tend to close the enhancement as WNF. [~alanb] What do you think?
11-10-2024
The same is applicable to class loader: JVMTI heap functions report reference from a Class to its class loader with ref kind JVMTI_HEAP_REFERENCE_CLASS_LOADER. JDK-6642881 made "classLoader" explicit field, so it's reported as JVMTI_HEAP_REFERENCE_FIELD. It makes sense to fix both cases together
10-10-2024