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