While 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 Model
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.


JVMTI Model
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.

JVM Spaces
JVM memory is divided into two categories: young generation space and old generation space. As the names imply, young generation space is meant for recently created objects and old generation space stores surviving objects that have lived to some extent. Young generation space is itself divided into three categories: Eden space and two survivor spaces. The JVM initially allocates objects in the Eden space, where most objects die and quickly are reclaimed. When Eden space fills up, it causes the JVM to perform a minor collection, when it moves some surviving objects to the old generation. (Note: Any new objects created inside the method go into Eden space and the objects space is reclaimed once the method exists. Class-level object variables hang around for the entire life of the objects.)


The two survivor spaces are for copying live objects, allowing young objects to remain in the young generation space longer. One survivor space is empty at any given time. It serves as the destination of the next copying collection of any living objects in the Eden space and the other survivor space. In Figure 1, survivor space S1 is empty while S0 is being used.

If objects get too old, or young generation space gets filled up, JVM promotes objects to the old generation space. When the old generation space gets filled up, the JVM performs a major collection to remove the unused objects and reclaim their space. A major GC collection takes a significant amount of time and can affect system performance. Therefore, developers must make sure that major collections do not happen too often in their applications.

Explicitly nulling the object variables reduces the burden on the JVM, which can make a difference. An alternative, using System.gc(), is not a good programming practice because it forces the System to recapture the old generation space, which can take a long time.


Java Profile Examples
Using two Java programs, MyApp.java and MyAppComplex.java, I started 10 different threads and created dummy objects (click here to download the programs). MyApp.java creates objects within the method and explicitly nulls them after use, while MyAppComplex.java creates a number of class-level objects and does not null them. These programs demonstrate the activity within young and old generation JVM spaces and their effect on performance. Both programs have similar functionality, but MyApp takes less time as it is more JVM-friendly. I used the standard Java profilers jconsole and jstat to monitor the running application.


Monitor the Performance of Your Java Application
Many profiler tools are available for monitoring the performance of your Java application (such as JProfiler and YourKitJavaProfiler), and they offer fine-grained control to the class and even method levels. This article demonstrated some internal details of JVMs with standard JDK tools.
With knowledge of JVM internals, Java developers can run their applications through the profilers and address all the bottlenecks before deploying them. This way, they can avoid OutOfMemory error failures and poor performance in production.