Name: dk106046 Date: 06/15/2004

OPERATING SYSTEM(S): Solaris 5.8

FULL JDK VERSION(S):
1.3.1_12-b03


1) Set the path to the java.
2) Unzip the jdk13bug.zip onto any directory (say /usr/tmp)
3) Ensure tha the directory containing the libmyprofiler.so is on the LD_LIBRARY_PATH
ie
LD_LIBRARY_PATH=/usr/tmp/jdk13bug/solaris:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
4) Run the testcase
java -Xrunmyprofiler PerformanceExample

In our profiler we enable JVMPI_EVENT_METHOD_ENTRY2 and JVMPI_EVENT_METHOD_EXIT, and keep
track of the method stack that we have seen so far. That is, every time we see a
JVMPI_EVENT_METHOD_ENTRY2 we push an item onto the method stack, and every time we see
JVMPI_EVENT_METHOD_EXIT, we pop an item from the method stack. This stack is kept track
of on a per-thread basis.
The problem we have been seeing is that after we receive a JVMPI_EVENT_METHOD_ENTRY2
(referencing an object in event->u.method_entry2.obj_id) we will subsequently see a
JVMPI_EVENT_OBJECT_FREE event on that obj_id BEFORE the corresponding
JVMPI_EVENT_METHOD_EXIT has occurred. That is, references to obj_id are still on the
method stack when the OBJECT_FREE event occurs. This doesn't make sense. If the JVM is
still executing some method on object obj_id, then it cannot free that object. Hence, either
the OBJECT_FREE event is erroneous, or METHOD_EXIT events are being lost somewhere.
The 'test' profiler (libmyprofiler.so) to replicate this problem is based upon
the jvmpi_example profiler available from the JVMPI spec website.
It's behaviour is as follows: It keeps track of the method stack on a per-thread basis.
Whenever a JVMPI_EVENT_METHOD_ENTRY2 occurs on some thread x, it pushes
event->u.method_entry2.obj_id onto the stack associated with thread x; and whenever a
JVMPI_EVENT_METHOD_EXIT occurs on thread x, it pops the stack associated with thread x.
Whenever a JVMPI_EVENT_OBJ_FREE event occurs, we check to make sure that the object being
freed is not referenced on any of the method stacks. If it is, an error message is printed:
ERROR> Freeing Object currently on a method stack!!!!
(Note, in this test profiler, we also handle JVMPI_EVENT_OBJECT_MOVE's if they occur, so
that all obj_id references in all the method stacks are updated as necessary).

This problem does not occur with the latest Windows JVMs on 1.3.1. A testcase on Windows can be
provided. This does not occur on 1.4.x and above, even on Solaris.

======================================================================
###@###.### 10/14/04 12:57 GMT