WebLogic JRockit 8.1 by BEA Systems
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
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.
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.
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).
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.
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.
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.
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.
Target Audience: Developers, system administrators, project managers
Pros: Certified J2SE 1.4 compatible
High-performance, server-oriented VM
Integrated monitoring system
Well-documented feature set
Cons: Consumes more memory than a traditional VM
BEA Systems, Inc.
2315 North First Street
San Jose, CA 95131
Platforms: Window NT/2000/XP, Red Hat Linux
Compaq Armada M700, 850 MHz Intel Pentium III
processor, 20GB disk, 576 MB RAM, Windows
2000 service pack 3
Kirk Pepperdine is the chief technical officer at Java Performance Tuning.com and has been focused on object technologies and performance tuning for the last 15 years. Kirk is a co-author of Ant Developer's Handbook(Sams).