JDK-8035288 : Make jvmti report references to signers as part of java/lang/Class optional
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2014-02-19
  • Updated: 2024-10-11
  • Resolved: 2017-04-04
Related Reports
Blocks :  
JDK-8003551 - Move Signers out to the JDK
Relates :  
JDK-8336804 - Drop callback from class to its signers with ref kind JVMTI_HEAP_REFERENCE_SIGNERS
Description
In JDK9, discontinue FollowReferences from reporting references to class signers.   This support was likely added because the reference to the signers was in the metadata for classes and not a direct field in the java/lang/Class instance.  The signers are not commonly set unless from the protection domain certificates array.   Not saving a signers field per java/lang/Class instance will save footprint directly.   The JVM will not have a signers field to follow for JVMTI so we would like to remove this uncommonly used callback.

Suggested change is to add an optional capability and only report references to signers in the java heap if this capability is supported.

See:  http://cr.openjdk.java.net/~coleenp/jvmti.html
Comments
Signers don't need to be moved. It would have saved space in mirror. Closing as WNF.
04-04-2017
If signers are moved to the JDK in a hashtable or something, they can't be reported in heap walking for classes because they wouldn't be per-class.
16-09-2014
> Can I just change the jvmti spec to say that we removed support for it after jdk8? No, I don't think this is ok. The spec is implemented by other VMs than hotspot which may want to report the signers. This looks more like something we should add to the release notes for Hotspot 1.9.0. The best suggestion so far is David's: "(Implementation specific: a VM will report a reference of this kind if the associated entity is not accessible via a field of the Class object)" That together with a release note that says that Hotspot will not report singers or protection domain should cover it. (Possibly David's wording should be changed to allow several dereferences from the Class to the information). > I guess I have to file a CCC but is that before or after the spec is reviewed? Does anyone actually know the process? I think these are parallel processes. The change has to be reviewed by both the CCC and on the open aliases.
27-03-2014
Can I just change the jvmti spec to say that we removed support for it after jdk8? http://oklahoma.us.oracle.com/~cphillim/jvmti.html I guess I have to file a CCC but is that before or after the spec is reviewed? Does anyone actually know the process?
25-03-2014
I like your wording above. I have a changeset that moves protection domain to java/lang/Class so that wording would cover that too. Since the implementation is walking the heap looking for things (what is this used for again? Is it used to set watchpoints on fields?) it might have trouble finding the signers array for a particular class since it would be in a hash table, but the user could walk the hashtable too if they want. This feature seems too closely tied to the Java implementation of these things.
21-02-2014
The spec doesn't say what will be returned when, it simply has a bunch of enumerations that denote the kind of reference found. The expectation that traversing a class will find a signers value comes more from the end user because of the existence of JVMTI_HEAP_REFERENCE_SIGNERS. The RI, as I understand it, must support everything. But I've emailed the PMO to query that. That said, it may be that we can add what we in the spec business refer to as "weasel words" to get around this. Looking at this: JVMTI_HEAP_REFERENCE_CLASS_LOADER 4 Reference from a class to its class loader. JVMTI_HEAP_REFERENCE_SIGNERS 5 Reference from a class to its signers array. JVMTI_HEAP_REFERENCE_PROTECTION_DOMAIN 6 Reference from a class to its protection domain. it strikes me that the reason these exist is because these references are not explicitly stored as fields in the Class object but logically they do represent "fields". So perhaps we can add: (Implementation specific: a VM will report a reference of this kind if the associated entity is not accessible via a field of the Class object) to each of the above?
21-02-2014
This change passes all of the jck (lang/vm) and nsk and jtreg hotspot tests. Thanks for finding this jck test. Can we change the wording of the spec to match the JCK test then? A VM implementation may return the signers array when looking at a class but is not required to (?) Then as the RI we are not required to support this?
20-02-2014
There is a single test in the JCK that looks at JVMTI_HEAP_REFERENCE_SIGNERS: vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html. The test does not verify that it actually gets a JVMTI_HEAP_REFERENCE_SIGNERS reference, it merely says that it ok to get one when looking at a class.
20-02-2014
Or remove support for reporting this field in InstanceKlass since it's not there anymore? Adding Robert Field. We don't seem to know why this capability was added in the first place or what it would be used for.
19-02-2014
But the RI, ie hotspot, will need to support this optional capability.
19-02-2014