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

Figure 1. Jstat Snapshot of a Running Application

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.

When I ran MyApp.java, it actively used the young generation space (see Figure 2).

Figure 2. Jstat Snapshot of MyApp.java

In the jconsole display in Figure 3, you can see that the old generation space is constant.

Figure 3. Jconsole Snapshot of Old Generation Space for MyApp.java

However, the Eden space is quite active (see Figure 4).

Figure 4. Jconsole Snapshot of Eden Space for MyApp.java

When I run MyAppComplex with a large number of objects hanging around, you can see that the old generation space keeps growing (see Figure 5).

Figure 5. Jconsole Old Generation Space Snapshot of MyComplexApp.java

At the same time, the young generation space is extremely busy swapping objects from young generation space to old generation space. The young generation space gets filled up pretty quickly, so the JVM performs frequent minor collections (see Figure 6).

Figure 6. Jconsole Eden Space Snapshot of MyAppComplex.java

Jstats shows that whenever the young generation space is emptied, the old generation space increases for MyAppComplex.java (see Figure 7).

Figure 7. Jstat Snapshot of MyAppComplex.java

The old generation space keeps increasing until the JVM determines it has a major collection. When the JVM cannot reclaim any memory space—even after a major collection, then the application starts slowing down (see Figure 8).

Figure 8. Jstat Snapshot of MyAppComplex.java

JDK 1.5 provides many command-line options to control the memory allocated to JVM spaces, such as –Xincgc, -Xloggc:, -Xms, -Xmx, etc. The standard jstat and jconsole provide a lot of information about the internals of the running JVM. As noted in Figure 2, MyApp.java’s old generation space memory usage is very little (16 to 20 percent). Though the default old generation space setting is 40 to 70 percent, keep it to less than 30 percent to prevent the JVM from interrupting your running application to do a major GC collection. The difference in running times between MyApp.java and MyAppComplex.java is the GC’s interference of 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.