Concurrent Mark and Sweep
The most widely used alternate collector in HotSpot is Concurrent Mark and Sweep
(CMS). This collector is only used to collect the old generation—it is used in con‐
junction with a parallel collector that has responsibility for cleaning up the young
CMS is designed for use only in low-pause applications, those
that cannot deal with a stop-the-world pause of more than a
few milliseconds. This is a surprisingly small class—very few
applications outside of financial trading have a genuine need
for this requirement.
CMS is a complex collector, and often difficult to tune effectively. It can be a very
useful tool in the developer's armory, but should not be deployed lightly or blindly.
It has these basic properties that you should be aware of, but a full discussion of
CMS is beyond the scope of this topic. Interested readers should consult specialist
blogs and mailing lists (e.g., the “Friends of jClarity” mailing list quite often deals
with performance-related questions related to GC):
• CMS only collects the old generation.
• CMS runs alongside application threads for most of the GC cycle, reducing
• Application threads don't have to stop for as long.
• Has six phases, all designed to minimize STW pause times.
• Replaces main STW pause with two (usually very short) STW pauses.
• Uses considerably more bookkeeping and lots more CPU time.
• GC cycles overall take much longer.
• By default, half of CPUs are used for GC when running concurrently.
• Should not be used except for low-pause applications.
• Definitely should not be used for applications with high-throughput
• Does not compact, and in cases of high fragmentation will fall back to the
default (parallel) collector.
The Garbage First collector (known as G1) is a new garbage collector that was
developed during the life of Java 7 (with some preliminary work done in Java 6). It
is designed to take over from CMS as the low-pause collector, and allows the user to
specify pause goals in terms of how long and how often to pause for when doing