Skip navigation.
Downloads | Product Documentation | Support

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:

- Setting the Heap Size
- Defining When a Memory Space will be Cleared
- Setting the Thread Stack Size

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>

`-Xmx` sets the maximum size of the heap. Use the following guidelines to determine this value:

- On IA32 the maximum possible heap size is about 1.8 GB (which is the largest contiguous address space the O/S will give a process).
- Because IA64 machines have a larger address space, the 1.8 GB limit does not apply.
- Typically, for any platform you don't want to use a larger maximum heap size setting than 75% of the available physical memory. This is because you need to leave some memory space available for internal usage in the JVM.

### 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 1536 MB.

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

Table 2-1 `-Xcleartype` Parameters

Use this parameter... | To clear space...
--- | ---
`gc` | During the garbage collection
`local` | When a thread-local area is allocated
`alloc` 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. | When that space is allocated for a new object

The preferable options are either `alloc` or `local`.

## Default

If the clear type is not set, the default is `alloc` on IA32 systems and `gc` 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-2 shows these defaults:

Table 2-2 Default Head Stack Sizes

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