Garbage Collection - IBM 170 Servers Manual

applications with a large number of classes. Running CRTJVAPGM with OPTIMIZE(*INTERPRET)
will create this program ahead of time, making the first startup faster.

Garbage Collection

Java uses Garbage Collection (GC) to automatically manage memory by cleaning up objects and memory
when they are no longer in use. This eliminates certain types of memory leaks which can be caused by
application bugs for applications written in other languages. But GC does have some overhead as it
determines which objects can be collected. Tuning the garbage collector is often the simplest way to
improve performance for Java applications.
The Garbage Collector in the i5/OS Classic VM works differently from collectors in Java VMs on other
platforms, and therefore must be tuned differently. There are two parameters that can be used to tune GC:
GCHINL (-Xms) and GCHMAX (-Xmx). The JAVA/RUNJVA commands also include GCHPTY and
GCHFRQ, but these parameters are ignored and have no effect on performance.
The Garbage Collector runs asynchronously in one or more background threads. When a GC cycle is
triggered, the Garbage Collector will scan the entire Java heap, and mark each of the objects which can
still be accessed by the application. At the end of this "mark" phase, any objects which have not been
marked are no longer accessible by the application, and can be deleted. The Garbage Collector then
"sweeps" the heap, freeing the memory used by all of these inaccessible objects.
A GC cycle can be triggered in a few different ways. The three most common are:
1. An amount of memory exceeding the collection threshold value (GCHINL) has been allocated since
the previous GC cycle began.
2. The heap size has reached the maximum heap value (GCHMAX).
3. The application called java.lang.System.gc( ) [not recommended for most applications]
The collection threshold value (GCHINL or -Xms, often referred to as the "initial heap size") is the most
important value to tune. The default size for V5R3 and later is 16 MB. Using larger values for this
parameter will allow the heap to grow larger, which means that GC will run less frequently, but each
cycle will take longer. Using smaller values will keep the heap smaller, but GC will run more often. The
best value depends on the number, size, and lifetime of objects in your application as well as the amount
of memory available to the application. Most applications will benefit from using a larger collection
threshold value – 96 MB is reasonable for many applications. For WebSphere applications on larger
systems, heap threshold values of 512 MB or more are not uncommon.
The maximum heap size (GCHMAX, or -Xmx) specifies the largest that the heap is allowed to grow. If
the heap reaches this size, a synchronous garbage collection will be performed. All other application
threads will have to wait while this GC cycle occurs, resulting in longer response times. If this
synchronous GC cycle is not able to free up enough memory for the application to continue, an
OutOfMemoryError will be thrown. The default value for this parameter is *NOMAX, meaning that
there is no limit to the heap size. In practice, a well behaved application will settle out to some steady
state heap size, so *NOMAX does not mean that the heap will grow infinitely large. Most applications
can leave this parameter at its default value.
One important consideration is to not allow the Java heap to grow beyond the amount of physical memory
available to the application. For example, if the application is running in the *BASE memory pool with a
size of 1 GB, and the heap grows to 1.5 GB, the paging rate will tend to get quite high, especially when a
GC cycle is running. This will show up as non-database page faults on the WRKSYSSTS command
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 7 - Java Performance 130