The JVMTI FollowReferences function returns NULL in the
jvmtiHeapReferenceInfoJniLocal.method field in most of the cases.
It has to be explained by the JVMTI Spec.


The following email exchange explains some details.

---------------------------------------------------------------------------------

Serguei Spitsyn wrote:

> This happend in my test followref003 where there is only a JVMTI agent thread.
> I guess, it is considered as attaching because it is not a java thread, right?
> Both JVMTI and JNI environments are passed to JVMTI agent through arguments.
> This situation is typical for JVMTI agents, so it is better to explain
> it in the FollowReferences spec.

Agents created -agentlib are on attached threads. With the exception of GC events, JVM TI events come in on attached threads. With a couple exceptions, you can't execute JVM TI functions except on attached threads. You can't execute JNI functions except on an attached thread.

> Robert,
> Do you agree this is a spec bug?

Absolutely.

> If so, I could submit a bug report.

Thanks

-Robert

>
> Thanks,
> Serguei
>
> Alan Bateman wrote:
>
>>
>> My memory is that the jmethodID is only NULL for the case where a native thread attaches, and then creates some JNI refs before calling into java code - is that right? I found a mail (from July 2005) where we talked about clarifying this but I don't see it in the spec (and I don't see a bugID to track it either).
>>
>> -Alan.



>> Serguei Spitsyn wrote:
>>
>>> Robert and Alan,
>>>
>>> The JVMTI spec defines the jvmtiHeapReferenceInfoJniLocal structure:
>>>
>>> Reference information returned for JVMTI_HEAP_REFERENCE_JNI_LOCAL references.
>>>
>>> typedef struct {
>>> jlong thread_tag;
>>> jlong thread_id;
>>> jint depth;
>>> jmethodID method;
>>> } jvmtiHeapReferenceInfoJniLocal;
>>>
>>> It specifies the 'method' field as follows:
>>> "method jmethodID The method executing in this frame."
>>>
>>>
>>> But NULL can be returned to callback in the field 'method'
>>> when frame is native (is not a java method).
>>>
>>> I have fixed the followref003 test to not fail when NULL is returned
>>> for JNI_LOCAL:
>>>
>>> # heapReferenceCallback: ref=REFERENCE_JNI_LOCAL, class_tag=0 , tag=0 , size=328, len=-1
>>> # ref_tag=0 , thr_tag=11 , thr_id=8, meth=0, loc=0, idx=0
>>> ^^^^^^
>>>
>>> Do we have to specify this situation in the JVMTI spec?
>>>
>>> Thanks,
>>> Serguei

Alan Bateman wrote:

> Serguei Spitsyn wrote:
>
>> This happend in my test followref003 where there is only a JVMTI agent thread.
>> I guess, it is considered as attaching because it is not a java thread, right?
>> Both JVMTI and JNI environments are passed to JVMTI agent through arguments.
>> This situation is typical for JVMTI agents, so it is better to explain
>> it in the FollowReferences spec.
>
> Okay, so this is the agent thread scenario I was thinking of. In that case the thread is a JavaThread but if my memory is correct there isn't a last java frame but there may be JNI refs. For that scearnio I pass the jmethodID as NULL - it seemed the reasonable thing to do but it needed to be specified.

Exactly.
This is the code in the jvmtiTagMap.cpp:
  if (java_thread->has_last_Java_frame()) {
    ...
  } else {
    // no last java frame but there may be JNI locals
    blk->set_context(thread_tag, tid, 0, (jmethodID)NULL);
    java_thread->active_handles()->oops_do(blk);
  }


>> Robert,
>> Do you agree this is a spec bug?
>> If so, I could submit a bug report.
>
>
>
> I see Robert's reply - can you submit a bug?

I'll submit a bug and assign it to Robert.

Thanks,
Serguei
---------------------------------------------------------------------