Proposed and developed by engineers at Red Hat, Shenandoah GC promises significantly low pauses. It is a region-based GC that collects garbage in a parallel and concurrent manner. It is interesting to note that the pause times are independent of the application's live data.

With hardware engineering and lower costs, servers have more memory and processing power than ever before. Modern applications are increasingly demanding lower pause times—with Service Level Agreement (SLA) applications that guarantee response times of 10 to 500 ms. To meet the lower end of this range, a GC should be able to accomplish multiple tasks, including the following:

• Use algorithms that enable programs to execute with the given memory
• Keep the pause times low (that is, below 10 ms)

Is this attainable with, say, a Java application that uses 200 GB memory? This isn't possible with the compacting algorithms, which will exceed the limit of 10 ms, even for compacting 10% of this memory. Shenandoah uses an algorithm that compacts the memory concurrently while the Java threads are running. In this case, objects are moved during a concurrent GC cycle and all of its references immediately access the newer copy.

Concurrent compaction isn't simple. When GC moves a live object, it must atomically update all references to the object, pointing to the new object. However, to find all of the references, the entire heap should be scanned; this sounds infeasible. To get around this, the Shenandoah GC adds a forwarding pointer to each object, with each use of that object going through that pointer. This simplifies the process of moving around objects. The Shenandoah GC thread or application thread can copy an object and use compare and swap to update the forwarding pointer. In case of contention, only one compare and swap will succeed. With the addition of the forwarding pointer, Shenandoah GC uses more space than other GC algorithms.

Each Shenandoah GC cycle consists of four phases. A Shenandoah GC cycle begins with Initial Marking, in which it stops the world and scans the root set. In phase two, that is, Concurrent Marking, it marks the live objects and updates references, concurrently. In the third phase, Final Marking, it stops the world and scans the root set again, copying and updating roots to updated copies. The last phase, Concurrent Compaction, evacuates live objects from the targeted regions.

Shenandoah is a region-based GC. It isn't a generational GC that focuses on collecting the youngest objects. This is based on the hypothesis that most objects die young. However, applications with caches hold on to the objects long enough, and so generational GC algorithms don't work with them. To get around this, Shenandoah uses the Least Recently Used (LRU) cache benchmark that enables it to keep its pause time low.

Shenandoah never compacts humongous objects (that is, objects that can't fit in one region and require multiple regions). If the Shenandoah GC cycle determines that a humongous object is no longer live, its region is immediately reclaimed.

The main target of Shenandoah GC is to increase the responsiveness of the JVM by lowering the count and duration of GC cycles.