Name: tb29552 Date: 01/31/2002


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]



A DESCRIPTION OF THE PROBLEM :
Thanks for the comments in bug 4363856

While JVMPI_GC_ROOT_JNI_GLOBAL are indeed being sent, it
seems to me that the globalref they are sent with does not
match the globalref sent to JVMPI_EVENT_JNI_GLOBALREF_ALLOC
and JVMPI_EVENT_JNI_GLOBALREF_FREE.

(Alloc and Free are consistent between themselves, the frees
match up with the allocs)

(I haven't tried on the very latest versions of 1.3.1, but
this definitely occurs on the RC)

[for the record on #4363856, I think a ThreadBlock root
means that thread is currently running & hence the thread
object is alive. But I'm just guessing]

REGRESSION. Last worked in version 1.2.2

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You can reproduce this using hprof. On 1.2.2 a program with
global references will produce lines like:

ROOT 4b3bd98 (kind=<JNI global ref>, id=2fcc60, trace=1)
ROOT 4b3c250 (kind=<JNI global ref>, id=2fcc64, trace=1)

They are absent in 1.4 not because the ROOT isn't being set,
but because hprof can't look up the jobject used as the
reference in it's hashtable (see hprof_jni.c) - it calls the
find() function during the heap dump.

I've also verified this in my own profiler, so it isn't
something strange in the hprof code.

It's hard to make a really small demo, because you need
native code to reliably create and hold a global reference.
 I'll put in some code snippets, if you'd like, email me and
I can send you a complete working test case (as a DLL & jar,
along with source).

EXPECTED VERSUS ACTUAL BEHAVIOR :
ROOT 4b3bd98 (kind=<JNI global ref>, id=2fcc60, trace=1)
ROOT 4b3c250 (kind=<JNI global ref>, id=2fcc64, trace=1)

(or similar)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
You need to call a native method like:

JNIEXPORT void JNICALL
Java_com_numega_maui_qa_objecttest_JniManager_createGlobalLockTo
  (JNIEnv* env, jclass, jobject o )
{
env->NewGlobalRef( o );
}

And call it from a java program

   createGlobalLockTo( new Object() );

and sleep while you hit ctrl-break to force a profiler data dump request.
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
As long as you properly track object move events, the object
id that is sent seems reliable. You can probably look up
the references that were allocated for that object ID.

It makes it hard to determine how many global refs there are
to an object if you didn't load early enough to see them all
allocated, though.
(Review ID: 139038)
======================================================================