the most common passage about CMSFullGCsBeforeCompaction, is:
< hr >CMSFullGCsBeforeCompaction is talking about how many more times full GC has to be executed before compression has been done since the last CMS concurrent GC execution. The default is 0, that is, under the default configuration, compression will be done every time CMS GC can"t stand it and needs to be transferred to full GC. Configuring CMSFullGCsBeforeCompaction to 10 will change the first condition mentioned above to do compression every 10 times for real full GC (instead of doing compression every 10 times for CMS and GC, which is not currently available in VM). This makes full GC do less compression, which makes it easier for CMS"s old gen to suffer from fragmentation problems. This parameter is originally used to configure the frequency of reducing full GC compression in order to reduce the pause time of some full GC. The algorithm used by CMS when fallback to full GC is mark-sweep-compact, but compaction is optional, fragmentation would be more severe if not done, but the pause time for full GC will be shorter this time; this is a trade-off.
< hr > what I know about CMS, is the following details:
1 CMS is not full GC, but CMS includes two Full GC, one is the initial tag and the other is retag. Because these two times cause Stop-The-world
https://www.jianshu.com/p/f77.
2 CMS to perform a serial Full GC
3 CMS after concurrent mode failure, the concurrent cleanup phase is to clear rather than compress
my question is, when jvm GC is set to CMS,
1 CMS will do a serial Full GC after concurrent mode failure. Is it mark-compression or mark-erase? In
2, "the real full GC is compressed every 10 times". Does Full GC refer to the serial GC in 1 above or what?
3 the following is a common saying that the four triggering conditions of, Full GC (major GC) are as follows
- when calling System.gc (), the system advises Full GC, not necessarily to do
- lack of space for the elderly
- insufficient metaspace or permanent generation space
- the average size of objects entering the old age after previous Minor GC is larger than the available memory of the old age (allocation guarantee mechanism)
because CMS is not full GC, so when Jvm GC is set to CMS, do the above four trigger conditions cause CMS? It"s still full GC?.