The JRockit engineers made two assumptions when they first designed JRockit. First, server VMs run for a long time and, second, memory is cheap and plentiful. This motto still rings true in BEA's offering of the 8.1 (J2SE 1.4.1_03) version of this product. And, unlike the more familiar JVMs, this VM comes with a face.

Acquiring and Installing JRockit
JRockit runs on the MS Windows and Red Hat Linux platforms and is available in a 25MB download. The install was as uneventful as all installs should be. As expected, the directory structure followed the standard JDK/JRE structure. There were some differences in the content, but all of the standard tools were present. What is missing are the familiar Javadoc and Java source JAR. Not having the Javadoc was not an issue as it's the same one that's provided by the JDK and the quantity of online documentation is overwhelming. In addition to ample information on how to tune the JVM, it included a guide that described how to extract the JRE from the distribution.

Using JRockit
The two tools that I use on a regular basis are IntelliJ IDEA and Ant. Configuring IntelliJ to use JRockit required only a few mouse clicks. The following code shows how to set the JVM attribute so that Ant will use JRockit. Unfortunately, the Javac task has no such attribute and JRockit is not in the list of available compilers. The easiest way around this limitation is to use the exec task to invoke the compiler.

<target name="listener">
<java classname="com.jpt.benchmarks.jrockit.EchoServer"
jvm="${JRockit.home}/bin/java" fork="yes">
<classpath>
<pathelement location="classes"/>
</classpath>
</java>
</target>

JRockit supports all the standard VM options and a number of the more "standard" nonstandard -X options (such as heap size and heap max size).

JRockit Features
The reason for using this VM is its feature set. Curiously enough, one of the most interesting features is that the VM lacks an interpreter. As a result, the VM must JIT every method that it encounters. This does result in longer start-up times and the VM will consume more memory. The upside is that once started, your server will run at speeds that are comparable to a natively compiled executable. HotSpot will still aggressively compile the welltrafficked portion of your application.

Other features of the VM include four garbage collectors, thread local object allocation, thin threads, and a rich set of verbose printing options. The garbage collectors include a generational stop and copy single-spaced concurrent, generational concurrent, parallel, and single-spaced stop the world. It's the latter two GC algorithms that are recommended for production systems. Included in the documentation is a very useful discussion on how to choose between them.

By default, each thread is allocated its own private space in the heap, and objects are in this space. While this feature will result in your application consuming more memory, it eliminates the need to synchronize on a global heap. If memory does become an issue, you can configure the VM to allocate on the global heap.

The verbose printing of information includes memory system, garbage collection, class loading, code generation, CPU, and code optimizations. Normally, I would spend some time on the usefulness of this type of information, but that discussion is cut short in favor of the unique set of management and monitoring capabilities that are included with this VM.

Managing and Monitoring the JRockit JVM
The current set of management and monitoring APIs in the JRockit JVM are proprietary. Having said this, they are actively involved with the JSR-174 expert group, busily defining a set of specifications for APIs to manage and monitor a JVM. You have to believe that JRockit's still maturing management console is a demonstration of the future of VM technology.

As is the case with the JPDA, the JVM must be started with the monitoring turned on. As can be seen in Table 1, the associated overhead is barely noticeable until the console manager is attached. Once attached, the console did consume more cycles than was expected in this test, though in others, the resource consumption was much lower.

The good news is, with this VM we can afford to turn on monitoring in production and attach a console when the need arises. The console displays current readings on CPU, memory, heap, and garbage collection. Figure 1 is a complete summary of heap, memory utilization, and GC statistics. The main panel includes a CPU utilization gauge.

Figure 1

In addition to these statistics, the console supports the notification framework, which listens on aspects and triggers rules whenever the specified set of conditions is met. A rule consists of a trigger and an action. The trigger defines the conditions that must be met before the action will be executed. The action is simply what needs to be done when the trigger fires. The notification framework offers a nice point of extensibility. Developers are free to define their own triggers and actions.

Attaching a JRockit Runtime Analyzer recorder to the VM allows you to collect runtime information that can be analyzed at a later time. In addition to heap and GC statistics, the recorder captures method optimizations and the execution profile. An example of the detailed GC statistics can be seen in Figure 2.

Figure 2

While the ability to monitor was limited to a few statistics, there was a good level of detail on heap and memory utilization. One capability that I've used in other tools that was missing from this analysis tool was the ability to overlay and manipulate graphs. This feature is very useful when you're attempting to correlate events. As basic as the presentation was, it did offer a lot of data that is otherwise very difficult (if not impossible) to obtain.

Conclusion
With all the emphasis on performance, it's not surprising that this VM consistently obtains the best results in the SPECjjb2000 benchmarks. It is this drive for performance that has motivated the JRockit engineers to build tools to monitor and manage the VM. And now, these tools are providing us all with insight into the future of how VMs will be monitored and managed. Though the current console is more about monitoring than managing, the future will include such capabilities as being able to alter the choice of GC to altering the size of the nursery.

In creating a server-centric VM, the engineers at JRockit have purposely traded memory for performance, which is a wise choice in this reviewer's humble opinion.

Snapshot
Target Audience: Developers, system administrators, project managers

Level: Intermediate

Pros: