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