Tuning JRockit JVM
|
 |
 |
|
|
 |
 |
Introduction to Tuning BEA JRockit JVM
BEA JRockit JVM automatically adapts to its underlying hardware and to the application running on it. You might wonder, why would anyone need to tune the JVM? The answer is that there are some things BEA JRockit JVM cannot know about your system. For example, how much memory do you want the JVM to use? You probably don't want the JVM to use most of the available memory. Or, how long should the maximum pauses be, to work best within the tolerances of your application? This guide will help answer those questions.
This Introduction includes information on the following subjects:
How BEA JRockit is Tuned
BEA JRockit JVM has a number of non-standard startup parameters, called -X options, that allow you to better tune the JVM for your specific application. This guide documents the different startup parameters and what you need to know about setting them to be able to tune the JVM to ensure optimal performance for your application.
JVM Tuning Terminology
Before continuing, there are some terms you should understand. You may already be familiar with some of the terms, especially if you have read any other documents about garbage collectors.
The garbage collector is the key to effectively managing BEA JRockit's memory system, which is the ultimate goal of JVM tuning. Garbage collection is the process of clearing dead objects from the heap, thus releasing that space for new objects.
Memory throughput measures the time between when an object is no longer referenced and the time that it's reclaimed and returned as free memory. The higher the memory throughput the shorter is the time between the two events. Moreover, the higher the memory throughput the smaller the heap you will need.
Garbage collector pause time is the length of time that the garbage collector stops all Java threads during a garbage collection. The longer the pause, the more unresponsive your system will be. The worst pause time and the average pause time are the two most interesting values you can use for tuning the system.
Thread-local allocation removes object allocation contention and reduces the need to synchronize between thread performing allocations on the heap. It also gives increased cache performance on a multi-CPU system, because it reduces the risk of two threads running on different CPUs having to access the same memory pages at the same time.
Thread-local allocation is not the same thing as thread-local objects, but many people tend to confuse the two terms. Thread-local allocation does not determine whether the objects can be accessed from a single thread only (that is, thread-local objects); thread-local allocation means that the thread has an area of its own where no other thread will create new objects. The objects that the thread creates in that area may still be reached from other threads.
What You'll Find in Tuning BEA JRockit JVM
This guide is divided into three sections:
- Tuning BEA JRockit JVM describes the basic tuning parameters for the JVM. The instructions in this section describe default and optimal heap and nursery settings and how to use them to tune the JVM.
- Basic Tuning Tips and Techniques contains some helpful hints for maximizing system performance by tuning BEA JRockit to provide either optimal memory throughput or minimal garbage collection pause times.
- Analyzing and Improving Application Performance shows you how to you can improve application performance by uncovering "hotpaths," or bottlenecks in processing, and either working around them or eliminating them completely.
