Tuning the JRockit JVM
|
 |
 |
|
|
 |
 |
Tuning BEA 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.
This section describes how to use these options to tune BEA JRockit. It includes information on the following subjects:
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.
Setting the Heap Size
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.
Setting the Initial and Minimum Heap Size
-Xms sets the initial and minimum size of the heap. For this, BEA recommends that you set it to the same size as the maximum heap size; for example:
-java -Xgcprio:throughput -Xmx:64m -Xms:64m myClass
Default
-server mode: will set the initial and minimal heap to 25% of the amount of free physical memory in the system, up to 64 MB and a minimum of 16 MB.
-client mode: will set the initial and minimal heap to 16 MB.
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.
To get a fixed heap size—for example, if you want a controlled environment—set -Xms and -Xmx to the same value.
Setting the Maximum Heap Size
-Xmx:<size>[k|K][m|M][g|G]
-Xmx sets the maximum size of 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.
Default
-server and -client modes: will set the total physical memory to the lesser of 75% of the total physical memory or 1 GB.
Setting a low maximum heap (-Xmx) compared to the amount of live data can affect performance by forcing JRockit to perform frequent garbage collections.
Encountering Out of Memory Errors
There are two types of out of memory errors in JRockit:
- The result of failed object allocation
- The result of failed allocation of native memory for internal use within JRockit
- When the out of memory is caused by a failed object allocation, the maximum heap size (
-Xmx) needs to be increased. - When the out of memory is caused by failed allocation of native memory, it means that the JRockit process uses too much memory in total. This limit is determined by the operating system. When this happens, it may help to decrease the maximum heap size (
-Xmx)to free more memory resources for the rest of the JRockit process.
Paging (Page Faults)
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.
When verbose memory outputs are enabled (-Xverbose:memory) a warning will be printed when there are many page faults during garbage collection.
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.
Setting the Size of the Nursery
-Xns:<size>[k|K][m|M][g|G]
-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.
Note: To display pause times, include the option-Xgcpause when you start BEA JRockit JVM.
The maximum size of a nursery cannot exceed 95% of the maximum heap size.
Default
-server mode: the default nursery size is 10 MB per CPU; for example, the default for a 4-CPU system would be 40 MB.
-client mode: the default nursery size is 2 MB.
Additionally, the default nursery will never exceed 25% of maximum heap size, unless you use -Xns to explicitly set it to something larger.
Setting the Thread Stack Size
-Xss<size>[k|K][m|M] sets the thread stack size.
Minimum Thread Stack Size
Minimum thread stack size is 16KB. If -Xss is set below the minimum value, thread stack size will default to the minimum value automatically.
Default
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:
