Skip navigation.

Tuning JRockit JVM

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

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


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


-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


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


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:

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.


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


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


Defining When a Memory Space will be Cleared


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


During the garbage collection


When a thread-local area is allocated


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.


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


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


32-bit Default

64-bit Default


64 kB

320 kB


128 kB

1 mB


Skip navigation bar  Back to Top Previous Next