Using WebLogic JRockit 8.1 SDK

Understanding WebLogic JRockit SDK

WebLogic 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 undertand what they can do. This section includes information on the following subjects:

For more detailed information on additional WebLogic JRockit SDK features, please refer to What's in the WebLogic JRockit 8.1 SDK?

The BEA WebLogic JRockit Management Console

The Management Console connects to the WebLogic 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 WebLogic 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 WebLogic JRockit JVM Management Console.

Code Generation and Optimization

WebLogic 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, WebLogic 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, WebLogic JRockit does not fully optimize all methods at start-up; in fact, it leaves many methods unoptimized throughout the entire application run. Instead, WebLogic JRockit chooses those functions whose optimization will most benefit application performance and only optimizes those methods.

WebLogic 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.

WebLogic 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 WebLogic 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)

WebLogic JRockit JVM manages memory by employing four different garbage collectors. These collectors work during runtime to clear the memory heap of expired objects, or "garbage." These four garbage collectors are:

Generational Copy, which divides the memory into two areas called "generations." Instead of allocating objects in one single space and garbage collecting that whole space when it gets full, most of the objects are allocated in the "young generation", called the nursery.
Single-Spaced Concurrent, one of two types of concurrent collectors, which does its work in parallel with ordinary processing; that is, it does not stop all Java threads to do the complete garbage collection. This is designed to support garbage collection without disruption and to improve multiprocessor garbage collection performance.
Generational Concurrent is the second type of concurrent collector WebLogic JRockit employs. Although very similar to a single-spaced concurrent collector, a generational concurrent garbage collector does its actual object allocation in a "nursery," reducing the need to do collection of the entire heap so often.
Parallel garbage collection, which stops all Java threads and uses all CPUs to perform a complete garbage collection of the entire heap.

For information on selecting and using garbage collectors, see Selecting and Running a Memory Management System.

Threads

WebLogic JRockit JVM can use one of two thread systems to maximize processing:

Native Threads which maps Java threads directly to the operating system threads, directly taking advantage of the operating system's thread scheduling and load balancing policies. Native Threads is the default thread system for WebLogic JRockit JVM.
Thin threads, wherein multiple Java threads are run on a singe operating system thread. This allows WebLogic JRockit to optimize thread scheduling, thread switching, and thread synchronization, while using less memory.

Warning: Thin threads is experimental functionality in this version of WebLogic JRockit, and is not recommended for general use. This feature is subject to change without notice.

For information on selecting a thread system, please refer to Selecting and Running a Thread System.