hile veteran C and C++ developers know how hard it is to debug software memory problems, younger Java developers don't need to learn about them because Java handles memory automatically using the garbage collector (GC). When a Java developer creates a new Java object, the Java Virtual Machine (JVM) allocates memory for it and then reclaims the memory when the object reference is lost. Thanks to this simple, straightforward concept, many small to midsized Java applications never fail due to memory problems. In the rare instance when a Java application does fail with an out of memory error, however, novice Java developers often find it difficult to address this problem. That's where Java profilers come in.
Java profilers connect to a running Java application's JVM and capture memory information. They use native interfaces to the JVM—the Java Virtual Machine Profiler Interface (JVMPI) for Java </=1.4.2 or the JVM Tool Interface (JVMTI) for Java >/=1.5.0—to get the profiling information. If you don't profile your large enterprise Java applications prior to releasing them to production, they can fail with
OutOfMemoryErrors or render poor performance over time. This article examines the JVMPI and JVMTI VM profiling models and shows how they provide in-depth analysis of the internals of the JVM.
JVMPI was an experimental feature in the Java 2 SDK. Sun intended tools vendors to use it to develop profilers that would work in conjunction with Sun's JVM. Similar to the Java AWT listener API, JVMPI was based on the event model.
Profiling tools that utilized JVMPI had to implement the function call interface and register for various events in order to get various VM memory stats. When a registered event occurred, the application's VM captured a memory snapshot by querying the object hierarchy. This was very time consuming and it interfered with the running application. Also, when the profiling tool registered all the exposed events, it slowed down the VM considerably. As a result, many vendors stayed away from developing profiling tools with this interface.
As JVMPI had some shortcomings and was not offering finer-grain control of the running JVM, Sun introduced JVMTI with JDK 5.0 as an experimental interface model to profile the JVM. It provides ways to both inspect the state and control the execution of applications running in the JVM. JVMTI supports the full breadth of tools that need access to JVM state, including but not limited to profiling, debugging, monitoring, thread analysis, and coverage analysis tools. The JVMTI model supports both sampling and instrumentation of the JVM.
JVMTI is a two-way (query and control) interface. A client of JVMTI can be notified of interesting occurrences through events. Using JVMTI, profilers can query and control the application through many functions, such as GetEnv, GetLoadedClasses, etc. The native in-process interface allows maximal control with minimal intrusion from the tool.