Tuning JRockit JVM

Tuning BEA JRockit JVM

Have you ever seen strange pauses in your application that you haven't been able to explain? Have you seen one or all CPUs pegged on 100% utilization and all the others on 0% and still very few transactions in your system? If you answered yes to either of these two questions, your application might have been suffering from the effects of a poorly performing garbage collector. Some fairly simple tuning of the memory management system can improve performance dramatically for many applications.

To provide the optimal out-of-the-box experience, BEA JRockit JVM comes with default values that adapt automatically to the specific platform on which you are running BEA JRockit JVM. Tuning BEA JRockit JVM is accomplished by using non-standard—or -X—command line options that you enter at startup. -X options are exclusive to BEA JRockit JVM. Use them to set the behavior of BEA JRockit JVM to better suit the needs of your Java applications.

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. If that doesn't solve your problem, please send an e-mail to support@bea.com

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 might be required by 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<size>

-Xms sets the initial and minimum size of the heap. For this, we recommend 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: 25% of the amount of free physical memory in the system, up to 64 MB and a minimum of 8 MB.

-client mode: 25% of the amount of free physical memory in the system, up to 16 MB and a minimum of 8 MB.

Setting the Maximum Heap Size

-Xmx:<size>

As a rule, you want to set the maximum heap size as high as possible, but not so high that it causes page faults for the application or for some other application on the same computer. Set the maximum heap size by using the -Xmx command-line option; for example:

-java -Xgcprio:throughput -Xmx:64m -Xms:64m myClass

Heap Sizing Guidelines

What these options configure is subject to change between releases.This depends on many things, for example your hardware platform, your operating system, and which BEA JRockit version you use. Some guidelines based upon these criteria are listed in Table 2-1.

Table 2-1 Heap Limitation by Platform

Platform	Amount of Heap You Can Run
32-bit platforms (IA32)	On 32-bit platforms running with normal operating systems, processes are limited to less than 2 GB. Additionally, the heap must share this memory with all other memory used, including all JNI memory used by the application, generated code, the thread stacks, heap control, and other internal structures. Although you can run with as much and more than 1.8 GB of heap, it is seldom recommended. A normal initial heap would be 1.6GB. If you run Windows, you can start with `/PAE` or `/3GB`, which enables the process size to be larger. For more information in /PAE and /3G, please refer to: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx Even in this situation, the heap must be in consecutive memory, which still limits it to less than 2GB. Note: This will change in a future BEA JRockit release. Some Linux operating systems support larger process size by default (for example, Red Hat Enterprise Linux 4.0) and others can be started with the `hugepage` kernel. This allows process to run with heaps as large as 2.7GB.
64-bit platforms (x86_64 and IA64)	64-bit platforms are not physically limited by the pointer size and the process size can grow to the supported limit. The limit is usually the amount of memory installed, but there can be further limitations imposed by the operating system version (different releases support different amounts, for example Windows 2003/Itanium only supports 16 GB, unless you're running the EE variant). Versions of BEA JRockit up to and including 1.4.2 (24.5.0) have a pointerset for the heap that uses a 32-bit index; therefore a heap larger than 24GB will crash the JVM. You should experience similar performance between releases assuming the hardware you run upon has enough memory installed (which means enough for both the Java process and the operating system).

Platform

Amount of Heap You Can Run

32-bit platforms (IA32)

On 32-bit platforms running with normal operating systems, processes are limited to less than 2 GB. Additionally, the heap must share this memory with all other memory used, including all JNI memory used by the application, generated code, the thread stacks, heap control, and other internal structures. Although you can run with as much and more than 1.8 GB of heap, it is seldom recommended. A normal initial heap would be 1.6GB.

If you run Windows, you can start with /PAE or /3GB, which enables the process size to be larger. For more information in /PAE and /3G, please refer to:

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Even in this situation, the heap must be in consecutive memory, which still limits it to less than 2GB.

Note: This will change in a future BEA JRockit release.

Some Linux operating systems support larger process size by default (for example, Red Hat Enterprise Linux 4.0) and others can be started with the hugepage kernel. This allows process to run with heaps as large as 2.7GB.

64-bit platforms (x86_64 and IA64)

64-bit platforms are not physically limited by the pointer size and the process size can grow to the supported limit. The limit is usually the amount of memory installed, but there can be further limitations imposed by the operating system version (different releases support different amounts, for example Windows 2003/Itanium only supports 16 GB, unless you're running the EE variant).

Versions of BEA JRockit up to and including 1.4.2 (24.5.0) have a pointerset for the heap that uses a 32-bit index; therefore a heap larger than 24GB will crash the JVM.

You should experience similar performance between releases assuming the hardware you run upon has enough memory installed (which means enough for both the Java process and the operating system).

Encountering OutOfMemory Errors

If you encounter OutOfMemory errors, you should increase the maximum heap size according to the guidelines listed above.

Default

-server and -client modes: The default value is the lesser of 75% of the total physical memory up to 1 GB.

Setting the Size of the Nursery

-Xns:<size>

-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 you are 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 ten CPU system would be 100 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.

Heap Sizing Guidelines

The following guidelines offer some hints on how best to size a heap to achieve optimal performance. Be aware that these guidelines are mainly valid for the -server (default) start-up option (see Setting the Default Garbage Collector).

To get a fixed heap size—for example, if you want a controlled environment—set -Xms and -Xmx to the same value.
To improve start-up performance, set -Xms to at least the approximate amount of live data. You can set -Xms to as much as twice the minimum amount of live data without disturbing automatic heap resizing. If -Xmx isn't set, or is set too low, frequent garbage collections can slow startup until BEA JRockit has grown the heap.
To avoid paging, do not set -Xmx higher than the amount of available physical memory in the system. Also, you must account for of the memory usage of other applications intended to run simultaneously with the JVM, as these will 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 BEA 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 might occur even if -Xmx isn't set. BEA JRockit will not shrink the heap if more than half the heap is filled with live data. Thus, BEA 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 a low maximum heap (-Xmx) compared to the amount of live data can affect performance by forcing BEA JRockit to perform frequent garbage collections. If you anticipate a "tight" heap (that is, the amount of live objects is close to the size of the heap) and the application allocates many short lived objects, we suggest you use a generational garbage collector (-Xgc:gencon) instead of a single-spaced garbage collector (-Xgc:singlecon and -Xgc:parallel).

Defining When a Memory Space will be Cleared

-Xcleartype:<gc|local|alloc>

-Xcleartype defines when the memory space occupied by an object that has been garbage collected will be cleared. When clearing is actually performed is specified by the selected parameter, as described in Table 2-2.

Table 2-2 -Xcleartype Parameters

Use this parameter...	To clear space...
`gc`	During the garbage collection
`local`	When a thread-local area is allocated
`alloc`	When that space is allocated for a new object Note: This is the preferred option if the objects allocated are very large (1 to 2 kilobytes). The `alloc` parameter is currently not available on IA64 systems.

Use this parameter...

To clear space...

gc

During the garbage collection

local

When a thread-local area is allocated

alloc

When that space is allocated for a new object

Note: This is the preferred option if the objects allocated are very large (1 to 2 kilobytes). The alloc parameter is currently not available on IA64 systems.

The preferable options are either alloc or local.

Default

If the -XclearType is not set, the default is alloc on IA32 systems and local on IA64 systems.

Setting the Thread Stack Size

-Xss<size>[k|K][m|M]

-Xss<size>[k|K] [m|M] sets the thread stack size in kilobytes.

Minimum Thread Size

Minimum thread stack size is 16 kilobytes. 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-3 shows these defaults:

Table 2-3 Default Head Stack Sizes

O/S	32-bit Default	64-bit Default
Windows	64 kB	320 kB
Linux	128 kB	1 mB