The Concurrent Mark Sweep (CMS) collector
The Concurrent Mark Sweep (CMS) collector (also referred to as the concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects. If fragmentation becomes a problem, allocate a larger heap.
Note: CMS collector on young generation uses the same algorithm as that of the parallel collector.
The CMS collector performs the following phases on the old generation of the heap:
Phase | Description |
(1) Initial Mark (Stop the World Event) |
Objects in old generation are “marked” as reachable including those objects which may be reachable from young generation. Pause times are typically short in duration relative to minor collection pause times. |
(2) Concurrent Marking | Traverse the tenured generation object graph for reachable objects concurrently while Java application threads are executing. Starts scanning from marked objects and transitively marks all objects reachable from the roots. The mutators are executing during the concurrent phases 2, 3, and 5 and any objects allocated in the CMS generation during these phases (including promoted objects) are immediately marked as live. |
(3) Remark (Stop the World Event) |
Finds objects that were missed by the concurrent mark phase due to updates by Java application threads to objects after the concurrent collector had finished tracing that object. |
(4) Concurrent Sweep | Collects the objects identified as unreachable during marking phases. The collection of a dead object adds the space for the object to a free list for later allocation. Coalescing of dead objects may occur at this point. Note that live objects are not moved. |
(5) Resetting | Prepare for next concurrent collection by clearing data structures. |
Next, let's review CMS Collector operations step by step.
The heap is split into three spaces.
Young generation is split into Eden and two survivor spaces. Old generation is one contiguous space. Object collection is done in place. No compaction is done unless there is a full GC.
The young generation is colored light green and the old generation in blue. This is what the CMS might look like if your application has been running for a while. Objects are scattered(分散的; 零散的) around the old generation area.
With CMS, old generation objects are deallocated(释放) in place. They are not moved around. The space is not compacted(压缩) unless there is a full GC.
Live objects are copied from the Eden space and survivor space to the other survivor space. Any older objects that have reached their aging threshold(阀值,临界值) are promoted to old generation.
After a young GC, the Eden space is cleared and one of the survivor spaces is cleared.
Newly promoted objects are shown in dark blue on the diagram. The green objects are surviving young generation objects that have not yet been promoted to old generation.
Two stop the world events take place: initial mark and remark. When the old generation reaches a certain occupancy(居住; 占有,占领) rate, the CMS is kicked off(开始).
(1) Initial mark is a short pause phase where live (reachable) objects are marked.
(2) Concurrent marking finds live objects while the application continues to execute.
Finally, in the (3) remark phase, objects are found that were missed during (2) concurrent marking in the previous phase.
Objects that were not marked in the previous phase are deallocated in place. There is no compaction.
Note: Unmarked objects == Dead Objects
After the (4) Sweeping phase, you can see that a lot of memory has been freed up. You will also notice that no compaction has been done.
Finally, the CMS collector will move through the (5) resetting phase and wait for the next time the GC threshold is reached.
===========END===========