Introduction to JRockit JDK

Understanding the BEA JRockit JVM

The BEA JRockit JVM has a number of important features that separate it from other JVMs on the market today. This section provides high-level descriptions of some of the more critical features to help you better understand what they can do. The BEA JRockit JVM consists of the following parts:

The Java Development Kit

The BEA JRockit Java development kit (JDK) is very similar to the Sun JDK, except that it includes a new JRE with the BEA JRockit JVM and some changes to the implementation of the Java class libraries (however, all of the class libraries have the same behavior in the BEA JRockit JDK as in the Sun JDK).

The Java Runtime Environment

The BEA JRockit implementation of the Java 2 runtime environment (JRE) includes the BEA JRockit JVM, class libraries, and other files that support the execution of applications written in the Java programming language.

The JRockit Management Console

The Management Console connects to the BEA JRockit JVM and provides real-time information about server behavior and resource availability, such as memory usage and profiling information. This gives you a powerful way of retrieving real-time profile data about your application.

The Management Console provides a unique advantage when deploying a commercial Java solution because it gives you greater control of the complex set of interrelated variables that may affect your application in production. Administrators can monitor the BEA JRockit JVM operating characteristics and the Java application, and be automatically notified of changes in resource availability or operating characteristics as they occur. Based on this information, administrators can identify bottlenecks in performance and change operating and environmental parameters to optimize performance and availability.

For more information on the Management Console, please refer to Using the JRockit JVM Management Console.

Code Generation and Optimization

The code generator in JRockit is running in the background during the entire run of your Java application to automatically adapt the code to run its best. The code generator works in three steps as described in Figure 2-1.

Figure 2-1 Overview of Road to Optimized Code for Your Java Application

Overview of Road to Optimized Code for Your Java Application

The first step of code generation is the Just In Time (JIT) compilation. This compilation allows your Java application to get started and run while the code that is generated is not highly optimized for the platform.

Compilation time is part of application execution time, thus compiling all of the methods with all available optimizations will negatively impact application performance, that is why the first step is a JIT compilation, and therefore, JRockit does not fully optimize all methods at start-up.

During the second phase, JRockit monitors all threads, in run-time, to find out which methods are taking the longest to run. The monitoring is done in the background in a special sample thread, which means that the performance of your application is not disturbed.

The sample thread identifies what each thread is executing and notes some of the execution history. This information is tracked for all the methods and when it is perceived that a method is experiencing heavy use—in other words, is "hot"—that method is marked for optimization. Usually, a flurry of such optimization opportunities occur in the application's early run stages, with the rate slowing down as execution continues.

During the third phase, JRockit runs an optimization round of the methods that JRockit has perceived as the most used—"hot"—methods. This optimization is run in the background and does not disturb the running application.

Memory Management (Garbage Collection)

Memory management relies on effective "garbage collection," the process of clearing dead objects from the heap, thus releasing that space for new objects. BEA JRockit uses a dynamic garbage collector that is based upon one of two priorities that you set: application throughput or duration of the pause times caused by garbage collection. The dynamic garbage collector uses predefined heuristics to determine, in runtime, which garbage collection algorithm to use for each application.

In some instances, dynamic garbage collection might not be the most effective way to recycle memory. In those cases, BEA JRockit also provides a number of "static" garbage collectors that can be started by specifying the actual collector (-Xgc:<collectorName>) at startup.

For information on selecting and using garbage collectors, see Using the BEA JRockit Memory Management System.