On 21/05/2013 11:56 PM, Coleen Phillimore wrote:
On 05/21/2013 09:29 AM, Staffan Larsen wrote:
When doing heap iteration with JVMTI, the spec requires callbacks from
the VM to the agent identifying the signers and protection domain
references. This is what tagMap does, see jvmtiTagMap.cpp:2464.
As long as it it still possible for JVMTI to find these references
(with ik->protection_domain() and ik->signers()), I think it's ok.
Okay. Thanks for the quick answer. I was going to rip this out (rats,
now I can't). I can get to both protection domain and signers through
the mirror.
We are working on moving the signers completely to the jdk and not
having the jvm know about them at all. Then we can't find the signers
through this interface. Should we file a CCC request to change the
JVMTI spec then?
You can access any Java object field from the JVM - you just need to add
it to java_classes.cpp :) I don't think you can just rip this out of the
JVMTI spec.
David
-----
Thanks,
Coleen
/Staffan
On 21 maj 2013, at 14:52, Coleen Phillimore
<coleen.phillim...@oracle.com> wrote:
I found during code review comment editing for my change that removes
signers and protection domain from the InstanceKlass, that JVMTI code
seems to have some sort of call back and knowledge of these fields in
instanceKlass.
</constant>
<constant id="JVMTI_REFERENCE_SIGNERS" num="5">
Reference from a class to its signers array.
</constant>
<constant id="JVMTI_REFERENCE_PROTECTION_DOMAIN" num="6">
Reference from a class to its protection domain.
If I remove these, will it cause incompatibilities? It's used
during jvmtiTagMap.cpp (whatever that's doing).
Thanks,
Coleen
