JVMTI is an API built into both JDK 5.0 and 6.0, enabling an aspect-oriented approach to dynamic analysis - such as performance and coverage analysis - without the overhead of ordinary AOP approaches.

We all have experienced the need to find that performance bottleneck or that last crucial bug making our most vocal client crazy.

IDEs allow us to break at certain instructions and inspect the state of the application, more or less manually. Not only is this approach tedious but it changes the dynamics quite significantly, making it useless for performance or synchronization issues.

Say that we want to find the number of invocations of the method doThis in the following application:

The immediate approach is to manually insert analytical logic, such as in

And then we just insert analytical statements for any analysis we want to perform, and add if-statements to enable/disable these statements where needed. Easy, right? NO!

We could always use an Aspect-Oriented framework, such as AspectJ or the AOP server from JBoss, but they often require you to recompile the code and always changes the dynamics of the code within the JVM, and come with significant tax on the runtime performance.

Fortunately, Sun has had various APIs for real-time "aspects" built into their JVMs, such as JVMDI (JVM Debugger Interface) or JVMPI (JVM Performance Interface) since JDK 1.2 - I think. With Java 5.0, these two APIs became deprecated as a new API was introduced: JVMTI (JVM Tool Interface), and in Java 6.0, the two older APIs are no longer implemented.

So, how do we use JVMTI?

It is a native interface, so we need to use it from C or C++.

Make sure you have a proper JDK installed - such as Java 5.0 or 6.0 from Sun, although other JVM vendors implement JVMTI quite extensively - and that you add the Java header directory to your include path. This header directory is found at $JDK_HOME/include.

The JVMTI "aspect" must contain a function called Agent_OnLoad, so the simplest aspect - here called JvmtiAspect - is

Compile it. NOTE: if you use OS X, you need to rename the generated dynamic library to JvmtiAspect.jnilib; the rationale behind that decision is beyond my cognitive capabilities.

So, let us inject this aspect. First of all, copy the dynamic library so it accesible by the JVM; such as the directory of the bytecode for JvmtiDemo. Second, specify that you want the JVM to load this aspect. This can be done from the command line or by setting an environment variable. We use the command line option here:


java -agentlib:JvmtiAspect JvmtiDemo


Yep, the aspect was loaded properly!

So what about actually performing some analysis?

JVMTI uses events and associated callbacks. One usually has to do three things for a specific event:

• Enable capability
• Enable event
• Register the actual callback function

The following revised version performs these three steps for the event METHOD_ENTRY:

Try to run the Java code again. You will se a lot of method entries. This is because all methods are analyzed, including those of the Java core library.

Let us restrict the methods of interest to doThis. Luckily, given a local identifier for the Java method entered, we can get the name, using the JVMTI function GetMethodName. There is some cleaning up needed for the returned strings as well. Look at the following version:

Now you will get the log output only when entering our method, doThis. So, finally, let us remove this analysis logic from the Java code and add it to the aspect, utilizing a callback function called Agent_Unload, which is invoked when the aspect is unloaded. This usually coincides with the application exiting. See the final aspect and the original Java code:

I hope this shed some light into the powers of JVMTI.

Happy analysis!