[IBM JVM] How to allocate large objects into Large Object Area on IBM SDK 1.4.2 and later

How to allocate large objects into Large Object Area on IBM SDK 1.4.2 and later

Problem(Abstract)

IBM Sovereign 1.4.2 SDK SR1 and later (build date of 20050209 and later) supports the configuration of Large Object Area to reserve the Java™ heap for allocating large objects (>=64 KB).

Cause

As objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the large object area (LOA) is allocated.
Fragmentation is genarally only an issue with the 1.4.2 SDK and prior. In the 1.5 SDK and later, the LOA size is automatically controlled by the garbage collector.

Resolving the problem

The LOA size can be explicitly configured in the following way:

WebSphere Application Server V6.0, V5.1 and V5.0 (Java 1.4.2)
WebSphere Application Server V6.1, V7.0 (Java 1.5, 1.6)


WebSphere Application Server V6.0, V5.1 and V5.0 (Java 1.4.2):
Use the -Xloratio command line option.

With this option specified, certain parts of the Java heap are reserved for large objects (>=64 KB). This part of the Java heap will never be used for small object allocation (<64 KB).

Example:

-Xloratio0.2

This command reserves 20% of the active Java heap (not 20% of -Xmx but 20% of the current size of the Java heap) to the allocation of large objects (>= 64 KB) only. When an allocation request for an object not less than 64 KB arrives, the process first tries to allocate from the remaining 80% of the heap. If it is unable to allocate, it then tries to allocate in the exclusively reserved area for large objects.

-Xmx should be changed to make sure that you don't reduce the size of the small object area, by using the following formula:

[New Xmx] = [Current Xmx] / (1 - [loratio])

For example, we need at least 1462 MB for -Xmx to use -Xloratio0.3 with current -Xmx1024 MB

1024 MB / (1 - 0.3) = 1462 MB

When to use:

Generally, thorough analysis of the verbosegc trace is needed to decide whether to configure the -Xloratio. Use the following information as a general guideline:

• If you see fragmentation of the Java heap because of large objects (>= 64 KB) and there is a significant number of allocation failures due to these objects, then you can enable Xloratio with 0.2 or 0.3.
  
• From the verbosegc if you see that 0.2 or 0.3 is being used up and the Java heap is still fragmented because of large objects, then consider increasing Xloratio to 0.4 or 0.5.

How to configure:

Add the -Xloratio to Generic JVM Arguments in administrative console:

IBM Where to set generic JVM arguments in WebSphere Application Server

See: Java Diagnostics Guide 1.4.2 The wilderness for further details.

IBM recommends that you reduce the size of large objects in your application. If not possible, use Xloratio. If Xloratio does not help, please contact IBM support for further assistance.

Note: -Xloratio is deprecated beginning with the 1.5 JVM and has no effect on the large object area



WebSphere Application Server V7.0, V6.1 (Java V1.6, V1.5)

Beginning with the 1.5 JVM the Garbage Collector automatically expands or shrinks the LOA, depending on usage. There is no need to explicitly set the size. The value can be manually limited as shown below, however it is not recommended.

Use the -Xloainitial and -Xloamaximum.

The options take values between 0 and 0.95 (0% thru 95% of the current tenure heap size).

The defaults are:

• -Xloainitial0.05 (5%)
• -Xloamaximum0.5 (50%)

Example:

-Xloainitial0.2 -Xlomaximum0.4

How to configure:

Add the -Xloainitial and -Xloamaximum to the Generic JVM Arguments in administrative console:

IBM Where to set generic JVM arguments in WebSphere Application Server

See: Java Diagnostics Guide 5 Large Object Area for further details
See: Java Diagnostics Guide 6 Large Object Area for further details.