[DeveloperWorks] Garbage collection in WebSphere Application Server V8, Part 2: Balanced garbage collection as a new option

Garbage collection in WebSphere Application Server V8, Part 2: Balanced garbage collection as a new option

Introduction

In a Java™ Virtual Machine (JVM), the garbage collector reduces the application developer's memory management burden. Garbage collection (GC) is an automated system that handles both the allocation and reclamation of memory for Java objects. This helps reduce the complexity of application development, but comes at a cost that can manifest itself as uneven performance through an application's lifetime, as well as disruptive long pauses that can impact application responsiveness.

Part 1 of this series described the garbage collection policies available in IBM WebSphere Application Server V8 and information for configuring the new default generational policy. This article discusses the 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, as shown in Figure 1.

Figure 1. Pause time goals of the balanced collector

The cost of garbage collection can be attributed to a number of factors. Some of the most important are:

• Total size of live data: As the number and size of objects that are live (that is, accessible to the application through a series of object references) in the system increases, the cost of tracing, or discovering, those live objects increases.
• Heap fragmentation: As objects become reclaimable, the associated memory must be managed to satisfy allocation. The cost associated with tracking this memory, making it available for allocation, and relocating live objects to coalesce free memory, can be high.
• Rate of allocation: The speed at which objects are allocated, along with their size, will dictate the consumption rate of free memory, and, in turn, the frequency of garbage collection. An application with a high rate of allocation might experience disruptive GC pauses more frequently.
• Parallelism: The garbage collector might use multiple threads for garbage collection. As more threads work to complete the collection in parallel, garbage collection pause times decrease.

A common pattern in recent Java applications is the use of in-heap data stores. Examples include in-memory databases or low latency caches, often seen in NoSQL solutions. These deployments typically have a relatively low number of available cores compared to the large amount of memory being managed. Responsiveness in these applications is key -- long GC pauses can interrupt keep-alive heartbeats in data grid systems, leading to false conclusions that nodes within the data grid have failed and forcing a node restart. This causes poor responsiveness, wasted bandwidth as grid nodes are restarted and repopulated, and increased pressure on surviving nodes as they struggle to service increased load.
Existing approaches to garbage collection use powerful techniques to effectively address many of today's GC pause time issues. However, increasing heap sizes and changes in data patterns are beginning to expose weaknesses in these traditional models.