An Introduction to JRockit Mission Control
Pages: 1, 2

JRockit Runtime Analyzer (JRA)

The JRA is a Java application and JVM profiler. It has been around for quite some time within the JRockit development team, and was originally created to let the JRockit developers find good ways to optimize the JVM based on real-world applications, but it has proven very useful to customers for solving problems in both production and development. There are many reasons why JVM users simply can't give JVM developers access to, or hand over, their entire applications. The JRA works like a flight recorder; it records how the Java application and the JVM behave for a preset period of time. The recording can then be analyzed using the JRA application, where, for example, call traces for hot methods, bad synchronization, and other important application/JVM behavior can be analyzed. The BEA Support organization uses JRA recordings from customers on a regular basis to help BEA customers resolve issues.

JRA consists of two parts: the recording engine in the JVM, and the GUI application you can use to analyze the resulting recording. The recording engine uses several sources of information including the JRockit Hot Spot Detector (also used by the optimization engine to decide what methods to optimize), the operating system, the JRockit Memory System (most notably the garbage collector), and the JRockit lock profiler, if enabled.

With the JRA tool you can easily analyze the information contained in the JRA recording by graphical means (see Figure 3). Graphs show pause times, heap usage, and the committed heap size during the recording period. Any individual garbage collection (GC) can be selected and very detailed information about that particular garbage collection is provided. You get call traces for the hot methods—not only the call traces leading up to the call of the method, but also the call traces portraying what was usually called next. The call traces also show whether or not an optimized version of the method was called.

Figure 3
Figure 3: BEA JRockit Runtime Analyzer (click the image for a full-size screen shot)

A heap histogram is taken at the beginning and at the end of the recording, revealing the heap usage per class, for instances of classes occupying more than 0.5 percent of the used heap space. The collected heap information is also used to render pie charts showing heap utilization.

The overhead while recording is very low—typically less than two percent. However, since JRA is forcing a full garbage collection at the beginning and at the end of the recording to generate the heap histogram data, there may be a spike at the beginning and at the end of a recording.

There are several ways to start a JRA recording:

  • Use the JRockit Management Console.
  • Use the JRCMD.
  • Use the JRockit extensions to the JMX-enabled java.lang.management classes.
  • Use the JRA -XXjra command-line parameters.

JRA recordings can also be triggered from the Management Console using Notification Rules; for example, a rule can be created to start a JRA recording when the CPU load has been above 90 percent for a minute.

As you can tell, the JRA is a powerful JVM and Java application profiler that provides:

  • Efficiency (typically less than 3 percent overhead) in profiling both the JVM and Java application.
  • Method call traces showing which paths were taken to get to the method, and what was called next.
  • Method hot spot table, showing which methods were invoked most often.
  • Very detailed garbage collection statistics, showing what happened during each individual GC.
  • Garbage collection strategy changes.
  • Graphical plots of heap usage and pausetimes.
  • Heap histograms showing the heap usage per class at the beginning and the end of the recording.
  • Detailed lock profiling, showing which locks were taken, if they were contended, how many times they were taken, and more.
  • Pie charts of heap usage per object size, including fragmentation.
  • Which methods were optimized during the recording.

For more information about using the JRA, see the JRockit Mission Control documentation.

JRockit Memory Leak Detector

The JRockit Memory Leak Detector is a tool to help you quickly discover memory leaks. Even though the automatic memory management of Java frees the developers of the burden to explicitly allocate and free memory used, memory leaks can still occur if the program keeps referencing objects that are no longer of any use.

The JRockit Memory Leak detector gives the user a trend analysis to quickly spot even slow memory leaks. The trend analysis shows the heap usage of your application per class. It will tell you how much space instances of the type are using, what fraction of the heap they are occupying, how many instances there are, and how quickly that usage is growing in bytes per second.

The JRockit Memory Leak Detector also provides the means to quickly drill down to the cause of the leak. A suspect type can be selected in the trend analysis table, and all the types having instances pointing to the selected type can be shown in a graph (see Figure 4). The nodes of the graph can be arbitrarily expanded to let the user back-track to what is ultimately causing the references to be held. Instances of a class can be shown and introspected, and all instances pointing to a selected instance can be shown in an instance graph. Allocation traces can be turned on so that all allocations of a certain class can be traced.

For examples and guidance on how to use this tool, see the JRockit Mission Control documentation, and the Memory Leaks, Be Gone! article on dev2dev.

Figure 4
Figure 4: BEA JRockit Memory Leak Detector (click the image for a full-size screen shot)

When a Memory Leak Detector session is started, a Memory Leak Server (MLS) starts. Depending on the JDK version of the JRockit you connect to, either the JMX connector in JLMEXT (5.0), or the Rockit Management Protocol (RMP) (1.4) will be used. Note that the protocols differ and that there are differences in networking characteristics and security. A Memory Leak Server is a native server with which the rest of the communication during the session takes place. On the client side a Java API is used to communicate with the native server (see Figure 5). The reason for using a native server is that if a serious memory leak condition occurs and JRockit runs out of Java heap, JRockit will no longer be able to run Java code.

Figure 5
Figure 5: BEA JRockit Memory Leak Detector communication (click the image for a full-size screen shot)

The Memory Leak Detector piggybacks on the mark phase of the garbage collector, adding some book-keeping to record the heap histograms (the memory statistics of the heap aggregated per class) and generate the trend analysis. One common solution to finding memory leaks in competing tools is to take several snapshots of the entire heap of an entire system, and then compare the snapshots. In a system with hundreds of gigabytes of heap or a system in a production environment, this approach may not be feasible. With the JRockit Memory Leak Detector, only the information you are interested in is sent over the wire, making the bandwidth demands very small. When using the allocation call trace functionality, only code involving allocation sites for the selected class is instrumented. Also, as soon as the session is over, or the allocation traces are turned off, the instrumentation is removed and the code involving these allocation sites returns to full speed.

To summarize, the JRockit Memory Leak Detector is an advanced analysis tool with a number of novel features:

  • It can perform a trend analysis that discovers even slow memory leaks.
  • It does the analysis online, piggybacking on the JRockit Memory Manager, instead of, for instance, dumping the entire heap to the client multiple times and examining the difference.
  • It provides an advanced user interface that lets you find and examine the relationships between the leaking type and other types, or the leaking instance and other instances.
  • The detector has a very low overhead and can be used to do the analysis online, in production.
  • No bytecode instrumentation is used; when analyzed with the Memory Leak Detector, the Java code will continue executing as if it were never connected. No Java code will be modified.

The JRockit Memory Leak Detector is arguably the best-in-class tool for discovering and finding the cause for Java memory leaks. For more information about the JRockit Memory Leak Detector, see the JRockit Mission Control documentation.

Conclusion

The JRockit JDK now contains a versatile tools suite for monitoring, managing, profiling, and eliminating memory leaks in your application. JRockit Mission Control is free for development use. It can be reliably used in production environments without leaving any trace in your system after it has been used, and with a much smaller performance overhead than comparable tools when it is actually in use.

Marcus Hirt is one of the founders of Appeal Virtual Machines, the company that created the Java Virtual Machine JRockit. He is currently working as Engineering Manager for the JRockit Mission Control team.