The need for a server-side JVM is evident. The increase in the number of Java applications on the servers, and the exponential rise in the number of clients accessing these Java applications, brings forth the shortcomings in the traditional Java VMs, which are more tuned towards client-side processing.

The first question that comes to mind when talking about JRockit is the comparison between the JRockit JVM and the Sun JVM. Although this article does not focus on this distinction, I will present a brief history of JRockit and then discuss the management and monitoring features introduced in it.

A few of the major issues with these JVMs are their ability to handle threads, the time taken for garbage collection, and the management of I/O operations. In a typical client-side application profile, 75% of the time a client JVM is running code, 20% of the time it's managing memory (garbage collection), and the remaining 5% of the time it's dealing with threads and I/O activity. On the server side the JVM spends about 25% of its time running code, 15% of its time managing memory, 30% managing threads, and 30% performing I/O.

JRockit was introduced by Appeal Virtual Machines, based in Stockholm, Sweden, and acquired by BEA in 2002. JRockit offers alternative thread management and memory management to fit the needs of these server-side applications. It also introduces a more adaptive code optimization based on runtime monitoring information. JRockit is fully J2SE certified. A handful of core classes have been modified for better performance, but the majority of classes are unchanged from the Sun JVM.

Interpreter Versus Compiler
A key distinction between JRockit and traditional JVMs is that JRockit does not interpret code. Instead it uses a fast JIT compiler to compile all methods it encounters. The result of this is slower start-up times and a larger memory footprint, but faster execution times in the long run. During execution, a background thread is constantly looking for frequently run code. Such code is aggressively optimized and replaced during runtime. This is called adaptive optimization.

Runtime Management Console
JRockit comes with the JRockit JVM Management Console, which currently is not included with any of the commonly used JVMs. The management console comprises a management server and a standalone Swing application that is the console. You can turn on the management server by passing the following flag to the JVM on start-up:

"-XManagement"

An interesting note is that the console can be used with any JVM, not just JRockit. You can start the console by using the following command:

"java -jar <jrockit-installdirectory>/
console/ManagementConsole.jar"

Figure 1 shows how you can use the console to connect to the server.

 
Figure 1: JRockit connection

I have changed the default Medical Records application that ships with BEA Platform 8.1 to use the JRockit JVM. Figure 2 shows the command window when the BEA WebLogic Server is starting up. Note on the top that I have enabled the JRockit management server. Towards the bottom of the window you can see that I am connecting to the management server using the management console.

 
Figure 2: WebLogic startup command window

When you talk about monitoring, there is always a performance impact that you have to accept when you are monitoring information. The JRockit management console can be run on the server or a remote machine, thereby reducing the overhead on the server. However, there is still some overhead on the monitored JVM. I recommend running the management console to monitor the JVM when needed (when you see problems) and then disconnect, so that there is minimal impact on the monitored JVM. The console has a notification feature that can trigger alerts based on thresholds for various variables. A few interesting events are

• CPU Load
• % of Used Heap
• Free Physical Memory
• JVM Absolute CPU Load
• % of Used Memory
• Average Time Spent in GC

 
Figure 3: Monitoring information

The console also allows profiling of userspecified methods, showing the number of times a given method is invoked. This is roughly like a profiler, but the user must specify the class and method. Similarly, the console can be used to count the number of times an exception was thrown. The user must specify the exception to be counted.

Integration with the WebLogic Console
Many developers, and especially the operations departments, complain that they have to use still another console. This is not true with JRockit. The standard WebLogic console integrates with the JRockit management server. You can get the same monitoring capability that you get using the JRockit management console through the standard BEA WebLogic console. However, remember that the WebLogic console can also be used to monitor the JRockit JVM, not any other JVM. This is primarily due to the lack of available monitoring features in other JVMs.

JRockit Runtime Analyzer Tool
The JRockit JVM is instrumented to provide runtime behavior regarding the Java application. Such information was not available previously. Various tools take an outside-in, after-the-fact approach on trying to extract such information by hooking into the JVM. The inside-out approach taken by JRockit provides more accurate information with less performance impact.

The JRockit Runtime Analyzer is used by BEA engineers internally to tune and refine the JVM. Only recently has BEA opened this to the entire BEA community. You can download this tool from the BEA site and use it to analyze your own Java applications.

Summary
This article talked about the management and monitoring capabilities of the JRockit JVM. Although monitoring always has some impact on performance (and don't believe anyone who says otherwise), the ability to monitor your applications through your development life cycle and in production environments is key. Monitoring allows you to quickly identify and pinpoint problems and defects. The rich data that monitoring can provide can have a huge impact on the overall robustness of your applications.

References