Tuning the Garbage Collector

Garbage collection (GC) reclaims the heap space previously allocated
to objects no longer needed. The process of locating and removing the dead
objects can stall any application and consume as much as 25 percent throughput.

Almost all Java Runtime Environments come with a generational object memory system and sophisticated GC algorithms.
A generational memory system divides the heap into a few carefully sized partitions
called generations. The efficiency of a generational
memory system is based on the observation that most of the objects are short
lived. As these objects accumulate, a low memory condition occurs forcing
GC to take place.

The heap space is divided into the old and the new generation. The new
generation includes the new object space (eden), and two survivor spaces.
The JVM allocates new objects in the eden space, and moves longer lived objects
from the new generation to the old generation.

The young generation uses a fast copying garbage collector which employs
two semi-spaces (survivor spaces) in the eden, copying surviving objects from
one survivor space to the second. Objects that survive multiple young space
collections are tenured, meaning they are copied to the
tenured generation. The tenured generation is larger and fills up less quickly.
So, it is garbage collected less frequently; and each collection takes longer
than a young space only collection. Collecting the tenured space is also referred
to as doing a full generation collection.

The frequent young space collections are quick (a few milliseconds),
while the full generation collection takes a longer (tens of milliseconds
to a few seconds, depending upon the heap size).

Other GC algorithms, such as the Concurrent Mark Sweep (CMS) algorithm,
are incremental. They divide the full GC into several incremental pieces.
This provides a high probability of small pauses. This process comes with
an overhead and is not required for enterprise web applications.

When the new generation fills up, it triggers a minor collection in
which the surviving objects are moved to the old generation. When the old
generation fills up, it triggers a major collection which involves the entire
object heap.

Both HotSpot and Solaris JDK use thread local object allocation pools for lock-free,
fast, and scalable object allocation. So, custom object pooling is not often
required. Consider pooling only if object construction cost is high and significantly
affects execution profiles.

Choosing the Garbage Collection Algorithm

Pauses during a full GC of more than four seconds can cause intermittent
failures in persisting session data into HADB.

While GC is going on, the Application Server isn’t running. If
the pause is long enough, the HADB times out the existing connections. Then,
when the application server resumes its activities, the HADB generates errors
when the application server attempts to use those connections to persist session
data. It generates errors like, “Failed to store session data,” “Transaction
Aborted,” or “Failed to connect to HADB server.”

To prevent that problem, use the CMS collector as the GC algorithm. This collector can cause a
drop in throughput for heavily utilized systems, because it is running more
or less constantly. But it prevents the long pauses that can occur when the
garbage collector runs infrequently.