In the post ‘Brief Introduction to Java Generation Memory‘ and ‘an introduction to young generation collection‘, I described the java generation memory and the young generation collection. In this post I will describe one Java garbage collector, name CMS.
CMS, which stands for Concurrent Mark-Sweep, garbage collector is one of the garbage collectors supported by Java HotSpot VM. It has less pause time compared with Serial garbage collector and Parallel garbage collector. This post will briefly describe the phases in the CMS garbage collector.
CMS garbage collector has the below phases during its garbage collection:
- the initial mark phase (pause)
- the concurrent marking phase
- the concurrent precleaning phase
- the remark phase (pause)
- the concurrent sweeping phase
Among these phases, the initial mark phase and the remark phase will cause the application to stop running. The other phases will not the pause the application. Let’s first look the initial mark phase.
1. the initial mark phase
The initial mark phase indicate the start of a CMS garbage collection cycle. During this phase, CMS will first pause the application and then identify the objects that can be immediately reachable from outside the tenured generation space. The pause time is relatively short, because the mark doesn’t transverse the whole object tree recursively.
2. the concurrent marking phase
After the initial mark phase, the application resumes to run and the phase comes to the concurrent marking phase. During this phase, CMS marks the living objects, which are transitively reachable from the objects being identified during the initial mark phase. However, because the application is running, the data fields of an object that has been visited may be updated to reference a new object. Due to this reason, not all the living objects are guaranteed to be marked during this phase. Identifying this kind of living objects is the job of the remark phase.
3. the remark phase
During the remark phase, CMS will first pause the application in order to avoid creating new living objects, and then revisit the objects that have been modified during the concurrent marking phase. These modified objects may potentially reference living objects that haven’t been already identified. After this phase, all the living objects are guaranteed to be marked now.
4. the concurrent precleaning phase
Although I introduce the concurrent precleaning phase after the remark phase, the concurrent precleaning phase in fact occurs before the remark phase. Because CMS will pause the application and revisit some amount of objects during the remark phase, the pause time will be affected linearly by the amount of the objects being revisited. To reduce the pause time of the application, the concurrent precleaning phase was invented to do the same job as the remark phase. During the concurrent precleaning phase, the application is not paused. CMS will revisit as many objects as possible, so that fewer objects need to be revisited during the remark phase and the application will be paused for a shorter period of time.
5. the concurrent sweeping phase
After the living objects are marked, CMS will sweep the java heap, deallocating the non-living objects, in order to reclaim the memory. However, CMS will not compact the living objects as the Parallel garbage collector does. This will leave free memory non-contiguous. This may waste part of the java heap memory, because some free memory hole may not be large enough to hold new objects. This will also affect the speed of the new objects allocation, because bumping the pointer method could not be used here. Even though there are these disadvantages, CMS still is a good garbage collector.
That are all the phases for the CMS garbage collector.