关于CMSFullGCsBeforeCompaction，网上最多的一段话是：

CMSFullGCsBeforeCompaction 说的是，在上一次CMS并发GC执行过后，到底还要再执行多少次full GC才会做压缩。默认是0，也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。 把CMSFullGCsBeforeCompaction配置为10，就会让上面说的第一个条件变成每隔10次真正的full GC才做一次压缩（而不是每10次CMS并发GC就做一次压缩，目前VM里没有这样的参数）。这会使full GC更少做压缩，也就更容易使CMS的old gen受碎片化问题的困扰。 本来这个参数就是用来配置降低full GC压缩的频率，以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact，但compaction是可选的，不做的话碎片化会严重些但这次full GC的暂停时间会短些；这是个取舍。

我所知道的关于CMS，有如下几个细节：
1 CMS不是full GC，但是CMS包括两次Full GC，一次是初始标记，一次是重新标记，因为这两次导致Stop-The-world
2 CMS在concurrent mode failure之后会进行一次串行Full GC
3 CMS的并发清理阶段是清除而不是压缩

我的问题是，在jvm GC设置为CMS时
1 CMS在concurrent mode failure之后会进行一次串行Full GC是标记-压缩还是标记-清除？
2 文中的“每隔10次真正的full GC才做一次压缩”，这里说的Full GC是指上面1中的串行GC还是什么？
3 常见下面的说法，Full GC（major GC）的四个触发条件如下

调用System.gc()时，系统建议Full GC，不一定进行
年老代空间不足
元空间或者永久代空间不足
历次Minor GC后进入老年代对象的平均大小大于老年代的可用内存（分配担保机制）
因为CMS不是full GC，那么当Jvm GC设置为CMS时，上面四个触发条件导致的是CMS吗？还是full GC？