Introduction to JRockit SDK

Understanding BEA JRockit SDK

BEA JRockit SDK 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 SDK features to help you better understand what they can do. This section includes information on the following subjects:

The SDK

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

The Java Runtime Environment

The BEA JRockit implementation of the Java 2 runtime environment for use by the SDK. The runtime environment includes the BEA JRockit JVM, class libraries, and other files that support the execution of programs written in the Java programming language.

The BEA 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 constant 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 BEA JRockit JVM Management Console.

Code Generation and Optimization

BEA JRockit differs from most JVMs in that it compiles the code at first use by implementing a JIT ("Just In Time") compiler. This ensures desirable application performance from the outset, albeit at the cost of a slightly longer start-up time. To expedite start-up, however, BEA JRockit does not use all possible compiler optimizations. While doing so might lead to even better performance early in the application run, that would result in slower start-up.

Compilation time is part of application execution time, thus compiling all of the methods with all available optimizations also negatively impacts application performance. Therefore, BEA JRockit does not fully optimize all methods at start-up; in fact, it leaves many methods unoptimized throughout the entire application run. Instead, BEA JRockit chooses those functions whose optimization will most benefit application performance and only optimizes those methods.

BEA JRockit can thus be seen to have two distinct, but cooperating, code generators: a JIT compiler, which resolves data from bytecode, through three levels of intermediate representation, to native code (assembly language); and an optimizing compiler, which optimizes targeted methods at each level of intermediate representation.

BEA JRockit uses a "sampler thread" to identify which functions merit optimization. This thread wakes up at periodic intervals and checks the status of several application threads. It 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 us—-in other words, is "hot"—that method is earmarked 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.

The optimizing compiler in BEA JRockit includes many of the best-known techniques for code generation, particularly for IA64 machines. This includes a sophisticated register allocator that takes full advantage of IA64's large register stacks.

Memory Management (Garbage Collection)

Garbage collection is the process of clearing dead objects from the Java heap to releasing that space for new objects, which, in turn, ensures efficient processing. BEA JRockit allows you to select a dynamic garbage collector that bases its collection algorithm on one of two priorities: memory throughput or duration of pause time caused by collection. The unified garbage collector is dynamic in that, as it runs, it uses predefined heuristics to determine which collection algorithm to use and changes that algorithm as the individual case might warrant. You do not need to specify the actual algorithm to run this garbage collector.

In some instances, dynamic garbage collection might not be the most effective way to free-up memory. In those cases, BEA JRockit also provides a number of "fixed" collectors that can be started either by specifying the actual collector (-Xgc:[collectorName]) or by default, as determined by the JVM mode you select at startup (-server and -server options).

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