How to understand CMS and CMSFullGCsBeforeCompaction?

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?.

Oct.11,2021

I don't know if you already have an answer to your question. I'll answer it. If it's not correct, please correct it.
1 CMS will do a serial Full GC after concurrent mode failure. Is it mark-compress or mark-erase?
the content you posted on this question has already been answered for you.
Compression is done only every 10 times for real full GC (instead of every 10 times for CMS and GC, there is currently no such parameter in VM).

if you make the answer clear, the answer is: it depends on your jvm parameter.
the parameter in the default scenario is-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0. This means that every time the full gc (flag is cleared), it will be compressed. So the answer is 100% mark-clear-compression. If your CMSFullGCsBeforeCompaction is set to 5, only one out of every six full gc, is mark-clear-compress.

In the article

2, "the real full GC is compressed every 10 times". Does Full GC refer to the serial GC in 1 above or what?
refers to the serial full gc of 1. In CMS scenario (JDK 8 scenario), all operations refer to parallel (parallel, which means that gc itself is multithreaded, and concurrent means that gc and user worker threads are running at the same time, except for concurrent mode failure and other reasons. Degenerate to single-threaded full gc.
makes it clear that CMS uses single-threaded garbage collection only when it is degraded to serial full gc for reasons such as concurrent mode failure. (in fact, it can also be multithreaded here, but at that time, due to human reasons, Google proposed a patch, but it was not closed in the end. Ali jdk incorporated it and can be turned on through the CMSParallelFullGC parameter, but most jdk do not have this function, so in the degradation scenario, you can only use single thread, that is, the serial gc in question 1)

3 specific problems have to look at the jvm source code, I do not remember very clearly, thinking that in memory, these four are all caused by serial full gc.

MySQL Query : SELECT * FROM `codeshelper`.`v9_news` WHERE status=99 AND catid='6' ORDER BY rand() LIMIT 5
MySQL Error : Disk full (/tmp/#sql-temptable-64f5-1b30947-340d5.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
MySQL Errno : 1021
Message : Disk full (/tmp/#sql-temptable-64f5-1b30947-340d5.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
Need Help?