Anyway, that is enough for introductions. As always, I do not really know what to do with my precious time and instead choose to waste it. I have been interested in java class instrumentation and the esoteric world of java under the covers ever since I attended a presentation by Mr.Ted Neward. In particular, I have been wanting to play with JVMTI. Doing so meant, I would need to enter the world of C programming, something I have seem to have forgotten since working with java. So what am I trying to do? I am wishing, what if during developing unit tests, I could:
- Force a Garbage collection of the JVM
- Check to see if the objects I allocated are cleaned out
- Determine what objects are on the heap
- Determine what the state of the different threads on the VM are...
- Determine what objects are reachable
- And More...
What is JVMTI? "The JVM tool interface (JVM TI) is a standard native API that allows for native libraries to capture events and control a Java Virtual Machine (JVM) for the Java platform"...That is the official statement, mine is "Power Baby, Power!". Read more about JVMTI, JVMPI and how agents work in this fantastic article by Kello O'Hair and Janice J.Heiss.
In particular, the folder JDK_HOME/demo/jvmti of your JDK has multiple demonstrations of JVMTI features. I spent quite sometime running the same and would recommend taking a look at the demo's for my fellow enthusiast.
So what am I looking for? What I would like to do is load a libary using JNI and use JVMTI to print debug information regarding my application state. In particular, I am looking to see whether or not my code cleans up after itself.
I have a class Foo that is rather plain and does the following. Note that the same could easily be replaced by a JUnit test:
public class Foo {
Bar b;
private static Bar BAR = new Bar();
public Foo() {
b = new Bar();
}
public static class Bar {}
public String sayHello() {
ProgramMonitor.dumpHeap();
return "Hello World";
}
public static void createFoo() {
ProgramMonitor.forceGC();
ProgramMonitor.dumpHeap();
new Foo().sayHello();
}
public static void main(String args[]) {
Foo.createFoo();
ProgramMonitor.forceGC();
ProgramMonitor.dumpHeap();
}
}
My code for the ProgramMonitor class is rather simple and uses JNI as shown below:
public class ProgramMonitor {
public static native int getNumberOfLoadedClasses();
public static native void dumpHeap();
public static native void forceGC();
static {
System.load(System.getProperty("jvmtilib"));
}
}
So what I am trying to accomplish. When an object of the "Foo" class is created, it results in the creation of the "Bar" class as well. In addition, when Foo.class is loaded, it creates a static reference to Bar as well. When the program is done with the "Foo" object that is instantiated, the Bar object should be gone, i.e., GCed. However, the static reference to Bar in the Foo class should still be available.
What if I could view this same happening and assert the same ?
As shown above, the ProgramMonitor.java invokes native methods. One can create a C header file from the class definition by executing the following command:
>javah -jni -classpath . ProgramMonitor
The above call results in the creation of a C header file called ProgramMonitor.h that looks like:
....
/*
* Class: ProgramMonitor
* Method: getNumberOfLoadedClasses
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_ProgramMonitor_getNumberOfLoadedClasses
(JNIEnv *, jclass);
/*
* Class: ProgramMonitor
* Method: dumpHeap
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_ProgramMonitor_dumpHeap
(JNIEnv *, jclass);
/*
* Class: ProgramMonitor
* Method: forceGC
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_ProgramMonitor_forceGC
(JNIEnv *, jclass);
.....
The above generated header file defines the JNI functions that one needs to implement. An C file that implements the JNI header functions is created, i.e., ProgramMonitor.c. Shown below are only some parts of the C file, ProgramMonitor.c:
...
#include "jni.h"
#include "jvmti.h"
#include "ProgramMonitor.h"
/* Check for JVMTI error */
#define CHECK_JVMTI_ERROR(err) \
checkJvmtiError(err, __FILE__, __LINE__)
static jvmtiEnv *jvmti;
.....
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
jint rc;
jvmtiError err;
jvmtiCapabilities capabilities;
jvmtiEventCallbacks callbacks;
/* Get JVMTI environment */
jvmti = NULL;
rc = (*vm)->GetEnv(vm, (void **)&jvmti, JVMTI_VERSION);
if (rc != JNI_OK) {
fprintf(stderr, "ERROR: Unable to create jvmtiEnv, GetEnv failed, error=%d\n", rc);
return -1;
}
CHECK_FOR_NULL(jvmti);
/* Get/Add JVMTI capabilities */
.....
/* Create the raw monitor */
err = (*jvmti)->CreateRawMonitor(jvmti, "agent lock", &(gdata->lock));
CHECK_JVMTI_ERROR(err);
/* Set callbacks and enable event notifications */
....
return JNI_VERSION_1_2;
}
JNIEXPORT jint JNICALL Java_ProgramMonitor_getNumberOfLoadedClasses(JNIEnv *env, jobject obj){
jclass *classes;
jint count;
(*jvmti)->GetLoadedClasses(jvmti, &count, &classes);
return count;
}
void dump() {
// Dump information....
.....
}
JNIEXPORT void JNICALL Java_ProgramMonitor_dumpHeap
(JNIEnv *env, jclass jclass) {
dump();
}
JNIEXPORT void JNICALL Java_ProgramMonitor_forceGC
(JNIEnv *env, jclass js) {
printf("Forcing GC...\n");
jvmtiError err = (*jvmti)->ForceGarbageCollection(jvmti);
CHECK_JVMTI_ERROR(err);
printf("Finished Forcing GC...\n");
}
The point to note from the above are that JNI_OnLoad method is called, a reference to the JVMTI environment is obtained and interest on jvmti capabilities are established. Note the forceGC call.
Now that we have the implementation of the library, we can build the same. The resulting library is called libProgramMonitor.so. So what we have now is a C library that obtains a handle to JVMTI and provides for methods to force garbage collection and provide information on the heap at any given time.
We are now ready to execute our Foo class and witness the output.
>java -Djvmtilib=/home/sacharya/jvmti-examples/libProgramMonitor.so -classpath . Foo
Forcing GC...
Finished Forcing GC...
Number of loaded classes 353
Heap View, Total of 35688 objects found.
Space Count Class Signature
---------- ---------- ----------------------
8 1 LFoo$Bar;
---------- ---------- ----------------------
Number of loaded classes 353
Heap View, Total of 35690 objects found.
Space Count Class Signature
---------- ---------- ----------------------
16 2 LFoo$Bar;
16 1 LFoo;
---------- ---------- ----------------------
Forcing GC...
Finished Forcing GC...
Number of loaded classes 353
Heap View, Total of 35679 objects found.
Space Count Class Signature
---------- ---------- ----------------------
8 1 LFoo$Bar;
---------- ---------- ----------------------
From the above, notice that the instance of Bar that was transiently created was reclaimed. The static reference to Bar however lingered as expected.
Conclusion:
We can easily add more methods to the ProgramMonitor class to provide information such as References, Threads etc. The ProgramMonitor library is not displaying all the loaded classes and is filtering out the ones that begin with "java" or "sun".
Using JVMTI can be so valuable in validating code and ensuring it behaves as expected at the Unit test level. I am aware that there are commercial software that do the same :-)...You can't blame me for playing ;-). JVMTI is powerful stuff and I am only feeling the temperature of the water here. I don't want to enter the "C" though ;-)! If Linux is for geeks, then so is C. I have reached the conclusion that Java is equivalent of Windows OS for the C programmer.
I am not quite sure whether the "ForceGarbageCollection" is indeed a gurantee of Garbage collection. I am curious regarding promotion of objects across different GC spaces and how the ratio effects the code.
Source:
The code shown above was developed on JDK1.16.X and run on a Linux OS. Easily made compatible though by looking at the examples in the standard jdk demo. In addition, the majority of the code is based of the heapViewer demo code. This example is only an "example".
As always, my source can be obtained from HERE
Running the Example:
Enusre you have JDK 1.6 installed and you are on Linux OS. Export JDK_HOME to your jdk home. Run javac to compile your sources. Run the makefile by typing "make" to build "libProgramMonitor.so". Finally run ">java -Djvmtilib=/home/sacharya/jvmti-examples/libProgramMonitor.so -classpath . Foo" replacing jvmtlib value with the location of the libProgramMontior file in your file system. I know I should have made a maven project, I should have also had the .java file compiled from the make file. Oh well! In addition, why couldn't I have used System.loadLibary() to load the JNI library file? I couldn't, as it didn't work even though I have LD_LIBRARY_PATH defined correctly and am too lazy to figure out why ;-) Also, a better test would have been have a more busy case where the CPU is really occupied to view the GC.
Ping me if you cannot run this example. I have tried the same on Suse 11 and Mandriva Spring.
Resources:
JVM Tool Interface (JVMTI): How VM Agents Work
Java Forum inspiration
Garbage Collection Forcing documentation
Heap Analyzer Tool - Worth checking out
Creating and Debugging a Profiling Agent with JVMTI
2 comments:
thanks for this example...it works fine
thanks for this example...it works fine
Post a Comment