Garbage collection in WebSphere Application Server

Garbage collection (GC) is an integral part of the Java Virtual Machine (JVM) as it collects unused Java heap memory so that the application can continue allocating new objects. The IBM JVM provided with IBM WebSphere Application Server provides four different GC policy algorithms:

-Xgcpolicy:optthruput

-Xgcpolicy:optavgpause

-Xgcpolicy:gencon

-Xgcpolicy:balanced

Default policy in WAS V8 was changed from -Xgcpolicy: optthruput to -Xgcpolicy: gencon .

optthruput:

The JVM allows object allocation continuously till it reaches the threshold value ie(<4% free java heap available). Once it reaches the threshold GC kicks on to clear the dead objects. If the Xmx is huge then there are possibilities of more pausetime but till it reaches the threshold value, application works fine.  

This collector uses a parallel mark-sweep algorithm.

This means that the collector first walks through the set of reachable objects, marking them as live data. A second pass then sweeps away the unmarked objects, leaving behind free memory than can be used for new allocations. The majority of this work can be done in parallel, so the collector uses additional threads (up to the number of CPUs by default) to get the job done faster, reducing the time the application remains paused.

optavgpause: The Concurrent Collector

The optavgpause policy (-Xgcpolicy:optavgpause) attempts to do as much GC work as possible before stopping the application, leading to shorter pauses. The same mark-sweep-compact collector is used, but much of the mark and sweep phases can be done as the application runs. Based on the program's allocation rate, the system attempts to predict when the next garbage collection will be required. When this threshold approaches, a concurrent GC begins.

As application threads allocate objects, they will occasionally be asked to do a small amount of GC work before their allocation is fulfilled. The more allocations a thread does, the more it will be asked to help out.

Meanwhile, one or more background GC threads will use idle cycles to get additional work done. Once all the concurrent work is done, or if free memory is exhausted ahead of schedule, the application is halted and the collection is completed.

This pause is generally short, unless a compaction is required. Because compaction requires moving and updating live objects, it cannot be done concurrently.

Gencon: This policy is meant for less pause time.

Java heap divided into Nursery and tenture. Initial allocations done on nursery area. Once it fill nursery area Scavenge GC occurs(Partial GC on Nursery area). This moves the long lived objects to tenure area and keeps the short lived at nursery. Once nursery and tenure space filled system GC kicks on to clear dead objects.

If the nursery space is not set properly then scavenge gc occurs often which halts the performance of the system. Excess GC always lead to performance impact of the system.

Results:

Reduced major collection frequency (Full GC)

Reduced Full GC elapsed time & pause time

Increase JVM throughput

Increase performance & capacity of your application

Balanced garbage collection policy, a new GC technology available in WebSphere Application Server V8, available through the command line option, -Xgcpolicy:balanced. The balanced collector aims to even out pause times and reduce the overhead of some of the costlier operations typically associated with garbage collection

This policy is available only on 64-bit platforms.

The policy is optimized for larger heaps; if you have a heap size of less than 4 GB you are unlikely to see a benefit compared to using the Gencon policy.
https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.zos.70.doc/diag/understanding/mm_gc_balanced_when.html