On 22 maj 2013, at 13:18, Coleen Phillimore <coleen.phillim...@oracle.com> wrote:
> On 5/22/2013 3:04 AM, Staffan Larsen wrote: >> On 22 maj 2013, at 06:35, David Holmes <david.hol...@oracle.com> wrote: >> >>> 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. >> I agree with David here - changing the JVMTI spec is not the solution. > > But there won't be a field in the mirror or anywhere for signers. We can get > the value from protection_domain.getCertificates() from the jdk but the jvm > doesn't currently do the upcall to java. Why does the jvmti spec dictate > implementation? I don't know the reasons for the JVMTI design here, but from a Java perspective there is a method Class.getSigners() and it is this relationship that JVMTI tries to capture. If this hasn't historically been a field in Class, then to only way to get this from JVMTI would have been something like the current design. So the JVMTI spec may have worked around a previous implementation limitation, and now we are stuck there. /Staffan
