Concurrent Mark-Sweep (CMS) Collector
Concurrent-Mark-Sweep collector is most popular garbage collector of Java. CMS collector is popular for its better throughput and less pause time. Because for many applications, end-to-end throughput is not as important as fast response time. For example gaming applications need fast response time to make their gaming experience better, if any game hang for a second only, it lost its charm. As you know young generation collections do not typically cause long pauses, because of its small size and less amount of live objects survived. However, old generation collections is uncertain, can impose long pauses, especially when large heaps are involved. To address this issue, the Java HotSpot JVM includes a collector called the concurrent-mark-sweep (CMS) collector, also known as the low-latency collector. If you are not aware about garbage collection fundamentals and object generations, then I will recommend you to first read my blog “How memory management (Garbage Collection) works in Java and difference types of Garbage Collectors in Java?”
Young Generation Collection Using the CMS Collector
The CMS collector collects the young generation in the same manner as the parallel collector. Because young generation collection do not typically take long pauses because of its small size. There is one more reason, as you know in young generation large amount of objects become garbage and get de-allocated at very first time of collection, which do not take much time and introduce very short pause.
Old Generation Collection Using the CMS Collector
Concurrent Mark Sweep collector play significant role in old generation garbage collection. CMS mainly works on four phases. Initial Mark, Concurrent Mark, Remark and Concurrent Sweep.
Most of the collection of the old generation using the CMS collector is done concurrently with the execution of the application. A collection cycle for the CMS collector starts with a short pause, called the initial mark, that identifies the initial set of live objects directly reachable from the application code.
Then, during the concurrent marking phase, the collector marks all live objects that are transitively reachable from this set. Because the application is running and updating reference fields while the marking phase is taking place, not all live objects are guaranteed to be marked at the end of the concurrent marking phase. To handle this, the application stops again for a second pause, called remark, which finalizes marking by revisiting any objects that were modified during the concurrent marking phase. Because the remark pause is more substantial than the initial mark, multiple threads are run in parallel to increase its efficiency.
At the end of the remark phase, all live objects in the heap are guaranteed to have been marked, so the subsequent concurrent sweep phase reclaims all the garbage that has been identified. Figure illustrates the differences between old generation collection using the serial mark-sweep-compact collector and the CMS collector.
Since some tasks, such as revisiting objects during the remark phase, increase the amount of work the collector has to do, its overhead increases as well. This is a typical trade-off for most collectors that attempt to reduce pause times. The CMS collector is the only collector that is non-compacting. That is, after it frees the space that was occupied by dead objects, it does not move the live objects to one end of the old generation. This saves time, but since the free space is not contiguous, the collector can no longer use a simple pointer indicating the next free location into which the next object can be allocated. Instead, it now needs to employ free lists. That is, it creates some number of lists linking together unallocated regions of memory, and each time an object needs to be allocated, the appropriate list (based on the amount of memory needed) must be searched for a region large enough to hold the object As a result, allocations into the old generation are more expensive than they are with a simple bump-the-pointer technique. This also imposes extra overhead to young generation collections, as most allocations in the old generation occur when objects are promoted during young generation collections. Another disadvantage the CMS collector has is a requirement for larger heap sizes than the other collectors. Given that the application is allowed to run during the marking phase, it can continue to allocate memory, thereby potentially continuing to grow the old generation. Additionally, although the collector guarantees to identify all live objects during a marking phase, some objects may become garbage during that phase and they will not be reclaimed until the next old generation collection. Such objects are referred to as floating garbage. Finally, fragmentation may occur due to lack of compaction. To deal with fragmentation, the CMS collector tracks popular object sizes, estimates future demand, and may split or join free blocks to meet demand.
Unlike the other collectors, the CMS collector does not start an old generation collection when the old generation becomes full. Instead, it attempts to start a collection early enough so that it can complete before that happens. Otherwise, the CMS collector reverts to the more time-consuming stop-the-world mark-sweep-compact algorithm used by the parallel and serial collectors. To avoid this, the CMS collector starts at a time based on statistics regarding previous collection times and how quickly the old generation becomes occupied. The CMS collector will also start a collection if the occupancy of the old generation exceeds something called the initiating occupancy. The value of the initiating occupancy is set by the command line option
–XX:CMSInitiatingOccupancyFraction=n, where n is a percentage of the old generation size. The default is 68.
In summary, compared to the parallel collector, the CMS collector decreases old generation pauses sometimes dramatically at the expense of slightly longer young generation pauses, some reduction in throughput, and extra heap size requirements.
The CMS collector can be used in a mode in which the concurrent phases are done incrementally. This mode is meant to lessen the impact of long concurrent phases by periodically stopping the concurrent phase to yield back processing to the application. The work done by the collector is divided into small chunks of time that are scheduled between young generation collections. This feature is useful when applications that need the low pause times provided by the concurrent collector are run on machines with small numbers of processors (e.g., 1 or 2). For more information on usage of this mode, search for “Tuning Garbage Collection with the 5.0 Java Virtual Machine”.
When to Use the CMS Collector
Use the CMS collector if your application needs shorter garbage collection pauses and can afford to share processor resources with the garbage collector when the application is running. (Due to its concurrency, the CMS collector takes CPU cycles away from the application during a collection cycle.) Typically, applications that have a relatively large set of long-lived data (a large old generation), and that run on machines with two or more processors, tend to benefit from the use of this collector. An example would be web servers. The CMS collector should be considered for any application with a low pause time requirement. It may also give good results for interactive applications with old generations of a modest size on a single processor.
Concurrent Mark Sweep Collector Selection
If you want the CMS collector to be used, you must explicitly select it by specifying the command line option
-XX:+UseConcMarkSweepGC. If you want it to be run in incremental mode, also enable that mode via the