We need to catch some specific cases when different kind of oop reference
(for instance, jobject) is passed to the JVMTI instead of jclass.
Please, see the discussion below of the jck bug 6551439:
JVMTI: FollowReferences and IterateThroughHeap return JVMTI_ERROR_NONE
if klass is not a valid class
----------------------------------------------------------------------------------------
Yes. Of course, it would be better if you can catch some of the cases, that is why the error code exists. In terms of checking in general it is important they don't imped performance (certainly not an issue in this case). Consistency is something to consider too: some functions checking and not others. If all functions could use the check you could consider putting in the wrapper so that it is automatic.
-Robert
Serguei Spitsyn wrote:
> Alan and Robert,
>
> Thank you for the help here!
> Then I agree that these jck tests are not valid.
>
> But I'm still thinking if it would be better to place an extra check for tipical
> case if some different kind of oop is passed to FollowReferences and
> IterateThroughHeap in place of jclass.
> First, these functions already return JVMTI_ERROR_INVALID_CLASS for some other cases.
> Second, the RetransformClasses() currently does this extra check:
> if (!k_mirror->is_a(SystemDictionary::class_klass())) {
> return JVMTI_ERROR_INVALID_CLASS;
> }
>
> Does it make sense?
>
> There is a comment for Yuri below.
>
> Robert Field wrote:
>
>> Alan Bateman wrote:
>>
>>> Serguei - I think we need Robert to jump in on this one. My memory is that JVMTI_ERROR_INVALID_CLASS is a function specific agent error and is not required to be returned. If someone passes a bad pointer into this function then what are we supposed to do? (I assume we crash).
>>
>> That is correct Alan. See the three error sections and the requirements on the implementation:
>>
>> http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#ErrorSection
> Yuri,
> Please, see at the link above (the section: "Function Specific Agent Errors").
>
> Thanks,
> Serguei
----------------------------------------------------------------------------------------
(for instance, jobject) is passed to the JVMTI instead of jclass.
Please, see the discussion below of the jck bug 6551439:
JVMTI: FollowReferences and IterateThroughHeap return JVMTI_ERROR_NONE
if klass is not a valid class
----------------------------------------------------------------------------------------
Yes. Of course, it would be better if you can catch some of the cases, that is why the error code exists. In terms of checking in general it is important they don't imped performance (certainly not an issue in this case). Consistency is something to consider too: some functions checking and not others. If all functions could use the check you could consider putting in the wrapper so that it is automatic.
-Robert
Serguei Spitsyn wrote:
> Alan and Robert,
>
> Thank you for the help here!
> Then I agree that these jck tests are not valid.
>
> But I'm still thinking if it would be better to place an extra check for tipical
> case if some different kind of oop is passed to FollowReferences and
> IterateThroughHeap in place of jclass.
> First, these functions already return JVMTI_ERROR_INVALID_CLASS for some other cases.
> Second, the RetransformClasses() currently does this extra check:
> if (!k_mirror->is_a(SystemDictionary::class_klass())) {
> return JVMTI_ERROR_INVALID_CLASS;
> }
>
> Does it make sense?
>
> There is a comment for Yuri below.
>
> Robert Field wrote:
>
>> Alan Bateman wrote:
>>
>>> Serguei - I think we need Robert to jump in on this one. My memory is that JVMTI_ERROR_INVALID_CLASS is a function specific agent error and is not required to be returned. If someone passes a bad pointer into this function then what are we supposed to do? (I assume we crash).
>>
>> That is correct Alan. See the three error sections and the requirements on the implementation:
>>
>> http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#ErrorSection
> Yuri,
> Please, see at the link above (the section: "Function Specific Agent Errors").
>
> Thanks,
> Serguei
----------------------------------------------------------------------------------------