CMS Collector and G1 Collector

Understanding the CMS Collector

CMS has three basic operations:

CMS collects the young generation (stopping all application threads).
CMS runs a concurrent cycle to clean data out of the old generation.
If necessary, CMS performs a full GC.

concurrent cycle

The JVM starts a concurrent cycle based on the occupancy of the heap. When it is
sufficiently full, the JVM starts background threads that cycle through the heap and
remove objects.
The concurrent cycle starts with an initial mark phase, which stops all the application
threads.This phase is responsible for finding all the GC root objects in the heap.
The next phase is the mark phase, and it does not stop the application threads.Since it is just a
marking phase, it hasn’t done anything to the heap occupancy, and so no data is shown
about that.
Next comes a preclean phase, which also runs concurrently with the application threads:
The next phase is a remark phase, but it involves several operations:
Next comes another concurrent phase—the sweep phase:
Next comes the concurrent reset phase:

concurrent mode failure:

When a young collection occurs and there isn’t enough room in the old generation to
hold all the objects that are expected to be promoted, CMS executes what is essentially
a full GC. All application threads are stopped, and the old generation is cleaned of any
dead objects, reducing its occupancy to 1,366 MB—an operation which kept the application
threads paused for a full 5.6 seconds. That operation is single-threaded, which is one reason it takes so long (and one reason why concurrent mode failures are worse as
the heap grows).
The second problem occurs when there is enough room in the old generation to hold
the promoted objects, but the free space is fragmented and so the promotion fails:
- As a result, in the middle of the young collection (when all threads were already stopped),
  CMS collected and compacted the entire old generation. The good news is that
  with the heap compacted, fragmentation issues have been solved (at least for a while).
  But that came with a hefty 28-second pause time. This time is much longer than when
  CMS had a concurrent mode failure because the entire heap was compacted; the concurrent
  mode failure simply freed objects in the heap. The heap at this point appears as
  it did at the end of the throughput collector’s full GC (Figure 6-2): the young generation
  is completely empty, and the old generation has been compacted.
- This occurs when permgen has filled up and needs to be collected; notice that the size
  of the CMS Perm space has dropped. In Java 8, this can also occur if the metaspace needs
  to be resized. By default, CMS does not collect permgen (or the metaspace), so if it fills
  up, a full GC is needed to discard any unreferenced classes.

summary

CMS has several GC operations, but the expected operations are
minor GCs and concurrent cycles.
Concurrent mode failures and promotion failures in CMS are
quite expensive; CMS should be tuned to avoid these as much as
possible.
By default, CMS does not collect permgen.

Understanding the G1 Collector

G1 is a concurrent collector that operates on discrete regions within the heap. Each
region (there are by default around 2,048 of them) can belong to either the old or new
generation, and the generational regions need not be contiguous. The idea behind having
regions in the old generation is that when the concurrent background threads look
for unreferenced objects, some regions will contain more garbage than other regions.
The actual collection of a region still requires that application threads be stopped, but
G1 can focus on the regions that are mostly garbage and only spend a little bit of time
emptying those regions. This approach—clearing out only the mostly garbage regions
—is what gives G1 its name: Garbage First.
That doesn’t apply to the regions in the young generation: during a young GC, the entire
young generation is either freed or promoted (to a survivor space or to the old generation).
Still, the young generation is defined in terms of regions, in part because it makes
resizing the generations much easier if the regions are predefined.
G1 has four main operations:
- A young collection
- A background, concurrent cycle
- A mixed collection
- If necessary, a full GC

young collection

The G1 young collection is triggered when eden fills up (in this case, after filling four
regions). After the collection, there are no regions assigned to eden, since it is empty.
There is at least one region assigned to the survivor space (partially filled in this example),
and some data has moved into the old generation.
23.430: [GC pause (young), 0.23094400 secs]
…
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]
Collection of the young generation took 0.23 seconds of real time, during which the GC
threads consumed 0.85 seconds of CPU time. 1,286 MB of objects were moved out of
eden (which was resized to 1,212 MB); 74 MB of that was moved to the survivor space
(it increased in size from 78 M to 152 MB) and the rest were freed. We know they were
freed by observing that the total heap occupancy decreased by 1,212 MB. In the general
case, some objects from the survivor space might have been moved to the old generation,
and if the survivor space were full, some objects from eden would have been promoted
directly to the old generation—in those cases, the size of the old generation would
increase.

concurrent G1 cycle

Finally, notice that the old generation (consisting of the regions marked with an O or
an X) is actually more occupied after the cycle has completed. That’s because the young
generation collections that occurred during the marking cycle promoted data into the old generation. In addition, the marking cycle doesn’t actually free any data in the old
generation: it merely identifies regions that are mostly garbage. Data from those regions
is freed in a later cycle.
The G1 concurrent cycle has several phases, some of which stop all application threads
and some of which do not. The first phase is an initial-mark phase. That phase stops all
application threads—partly because it also executes a young collection:
- As in a regular young collection, the application threads were stopped (for 0.28 seconds),
  and the young generation was emptied (71 MB of data was moved from the young
  generation to the old generation). The initial-mark output announces that the background
  concurrent cycle has begun. Since the initial mark phase also requires all application
  threads to be stopped, G1 takes advantage of the young GC cycle to do that
  work. The impact of adding the initial mark phase to the young GC wasn’t that large: it
  used 20% more CPU cycles than the previous collection, even though the pause was
  only slightly longer. (Fortunately, there were spare CPU cycles on the machine for the
  parallel G1 threads, or the pause would have been longer.)
Next, G1 scans the root region:
- 350.994: [GC pause (young)
  351.093: [GC concurrent-root-region-scan-end, 0.6100090]
  351.093: [GC concurrent-mark-start],
  0.37559600 secs]
- This takes 0.58 seconds, but it doesn’t stop the application threads; it only uses the
  background threads. However, this phase cannot be interrupted by a young collection,
  so having available CPU cycles for those background threads is crucial. If the young
  generation happens to fill up during the root region scanning, the young collection
  (which has stopped all the application threads) must wait for the root scanning to complete.
  In effect, this means a longer-than-usual pause to collect the young generation.
- The GC pause here starts before the end of the root region scanning, which (along with
  the interleaved output) indicates that it was waiting. The timestamps show that application
  threads waited about 100 ms—which is why the duration of the young GC pause
  is about 100 ms longer than the average duration of other pauses in this log.
After the root region scanning, G1 enters a concurrent marking phase. This happens
completely in the background; a message is printed when it starts and ends:
- 111.382: [GC concurrent-mark-start]
  ….
  120.905: [GC concurrent-mark-end, 9.5225160 sec]
Concurrent marking can be interrupted, so young collections may occur during this
phase. The marking phase is followed by a remarking phase and a normal cleanup phase:
- 120.910: [GC remark 120.959:
  [GC ref-PRC, 0.0000890 secs], 0.0718990 secs]
  [Times: user=0.23 sys=0.01, real=0.08 secs]
  120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]
  [Times: user=0.04 sys=0.00, real=0.01 secs]
These phases stop the application threads, though usually for a quite short time. Next
there is an additional cleanup phase that happens concurrently:
- 120.996: [GC concurrent-cleanup-start]
  120.996: [GC concurrent-cleanup-end, 0.0004520]
And with that, the normal G1 cycle is complete—insofar as finding the garbage goes, at
least. But very little has actually been freed yet. A little memory was reclaimed in the
cleanup phase, but all G1 has really done at this point is to identify old regions that are
mostly garbage and can be reclaimed (the ones marked with an X in Figure 6-7).

mixed GCs.

Now G1 executes a series of mixed GCs. They are called mixed because they perform
the normal young collection, but they also collect some number of the marked regions
from the background scan.
As is usual for a young collection, G1 has completely emptied eden and adjusted the
survivor spaces. Additionally, two of the marked regions have been collected. Those
regions were known to contain mostly garbage, and so a large part of them was freed. Any live data in those regions was moved to another region (just as live data was moved
from the young generation into regions in the old generation). This is why G1 ends up
with a fragmented heap less often than CMS—moving the objects like this is compacting
the heap as G1 goes along.
79.826: [GC pause (mixed), 0.26161600 secs]
….
[Eden: 1222M(1222M)->0B(1220M)
Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]
[Times: user=1.01 sys=0.00, real=0.26 secs]
Notice that the entire heap usage has been reduced by more than just the 1,222 MB
removed from eden. That difference (16 MB) seems small, but remember that some of
the survivor space was promoted into the old generation at the same time; in addition,
each mixed GC cleans up only a portion of the targeted old generation regions. As we
continue, we’ll see that it is important to make sure that the mixed GCs clean up enough
memory to prevent future concurrent failures.
The mixed GC cycles will continue until (almost) all of the marked regions have been
collected, at which point G1 will resume regular young GC cycles. Eventually, G1 will
start another concurrent cycle to determine which regions should be freed next.

full GC

As with CMS, there are times when you’ll observe a full GC in the log, which is an
indication that more tuning (including, possibly, more heap space) will benefit the application
performance. There are primarily four times when this is triggered:
Concurrent mode failure
- G1 starts a marking cycle, but the old generation fills up before the cycle is completed.
  In that case, G1 aborts the marking cycle:
- 51.408: [GC concurrent-mark-start]
  65.473: [Full GC 4095M->1395M(4096M), 6.1963770 secs]
  [Times: user=7.87 sys=0.00, real=6.20 secs]
  71.669: [GC concurrent-mark-abort]
- This failure means that heap size should be increased, or the G1 background processing
  must begin sooner, or the cycle must be tuned to run more quickly (e.g., by
  using additional background threads).
Promotion failure
- G1 has completed a marking cycle and has started performing mixed GCs to clean
  up the old regions, but the old generation runs out of space before enough memory
  can be reclaimed from the old generation. In the log, a full GC immediately follows
  a mixed GC:
- 2226.224: [GC pause (mixed)
  2226.440: [SoftReference, 0 refs, 0.0000060 secs]
  2226.441: [WeakReference, 0 refs, 0.0000020 secs]
  2226.441: [FinalReference, 0 refs, 0.0000010 secs]
  2226.441: [PhantomReference, 0 refs, 0.0000010 secs]
  2226.441: [JNI Weak Reference, 0.0000030 secs]
  (to-space exhausted), 0.2390040 secs]
  ….
  [Eden: 0.0B(400.0M)->0.0B(400.0M)
  Survivors: 0.0B->0.0B Heap: 2006.4M(2048.0M)->2006.4M(2048.0M)]
  [Times: user=1.70 sys=0.04, real=0.26 secs]
  2226.510: [Full GC (Allocation Failure)
  2227.519: [SoftReference, 4329 refs, 0.0005520 secs]
  2227.520: [WeakReference, 12646 refs, 0.0010510 secs]
  2227.521: [FinalReference, 7538 refs, 0.0005660 secs]
  2227.521: [PhantomReference, 168 refs, 0.0000120 secs]
  2227.521: [JNI Weak Reference, 0.0000020 secs]
  2006M->907M(2048M), 4.1615450 secs]
  [Times: user=6.76 sys=0.01, real=4.16 secs]
- This failure means the mixed collections need to happen more quickly; each young
  collection needs to process more regions in the old generation.
Evacuation failure
- When performing a young collection, there isn’t enough room in the survivor
  spaces and the old generation to hold all the surviving objects. This appears in the
  GC logs as a specific kind of young GC:
- 60.238: [GC pause (young) (to-space overflow), 0.41546900 secs]
- This is an indication that the heap is largely full or fragmented. G1 will attempt to
  compensate for this, but you can expect this to end badly: G1 will resort to performing
  a full GC. The easy way to overcome this is to increase the heap size,
Humongous allocation failure
- Applications that allocate very large objects can trigger another kind of full GC in
  G1; see “G1 allocation of humongous objects” on page 169. There are no tools to
  diagnose that situation specifically from the standard GC log, though if a full GC
  occurs for no apparent reason, it is likely due to an issue with humongous allocations.

Quick Summary

G1 has a number of cycles (and phases within the concurrent
cycle). A well-tuned JVM running G1 should only experience
young, mixed, and concurrent GC cycles.
Small pauses occur for some of the G1 concurrent phases.
G1 should be tuned if necessary to avoid full GC cycles.