Tuning the JRockit JVM
To provide the optimal out-of-the-box experience, BEA JRockit JVM comes with default values that try to adapt automatically to the specific application you are running on which you are running BEA JRockit JVM. Tuning BEA JRockit JVM is accomplished by using extended options—or
-X command line options that you enter at startup. The
-X options are exclusive to BEA JRockit JVM and can differ greatly between JVMs on the market. Use them to set the behavior of BEA JRockit JVM to better suit the needs of your Java application.
Note: If BEA JRockit behaves in some unexpected way, please consult the BEA JRockit Developers FAQ or you can also search for solutions to your problem in the BEA JRockit developer newsgroup.
System performance is greatly influenced by the size of the Java heap available to the JVM. This section describes the command line options you use to define the initial and maximum heap sizes and the size of any nursery that would be required by the generational garbage collectors. It also includes key guidelines for help you determine the optimal heap size for your BEA JRockit implementation.
To improve start-up performance, set
-Xms to at least the approximate amount of live data. If
-Xms isn't set, or is set too low, frequent garbage collections can slow startup until JRockit has grown the heap.
The default maximum heap size is a dynamic value determined by the amount of free physical memory in the system. If
-Xmx is not set, the Java heap can grow up to the lesser of 75% of the total physical memory or 1 GB unless there is risk that growing the heap will cause paging. Paging may still occur, but will be avoided as much as possible.
-Xmx) needs to be increased.
-Xmx)to free more memory resources for the rest of the JRockit process.
Paging may cause severe performance problems for your application and long garbage collection pauses. To avoid paging, do not set
-Xmx to more than 75% of the physical memory of the system. Also, remember to account for the memory usage of other applications intended to run simultaneously with JRockit, as these impact memory availability.
If the amount of free memory in the system varies widely, you might not want to set
-Xmx at all. This will prevent JRockit from growing the heap when there is too little memory in the system. Be aware that this will throw an OutOfMemoryError if object allocation fails with the current heap size and the heap cannot grow without causing paging.
Paging may occur even if
-Xmx isn't set. JRockit will not shrink the heap if more than half the heap is filled with live data. Thus, JRockit might not always be able to shrink the heap if the amount of free memory is reduced after JRockit has been started; for example, when another application is started.
-Xns sets the size of the young generation (nursery) in generational garbage collectors. Optimally, you should try to make the nursery as large as possible while still keeping the garbage collection pause times acceptably low. This is particularly important if your application is creating a lot of temporary objects.
If the thread stack size has not been set the default value depends on the platform on which BEA JRockit is running. Table 2-1 shows these defaults: