Need help with change

Staffan Larsen staffan.larsen at oracle.com
Wed May 22 04:35:24 PDT 2013


On 22 maj 2013, at 13:18, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> On 5/22/2013 3:04 AM, Staffan Larsen wrote:
>> On 22 maj 2013, at 06:35, David Holmes <David.Holmes at 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



More information about the serviceability-dev mailing list