garbage-collection - 是否-XX :+CMSIncrementalMode run on application threads or in GC-dedicated threads?

Question

阅读Really? iCMS? Really?时在这个博客中，有一句话引起了我的注意:

The concurrent phases are typically long (think seconds and not milliseconds). If CMS hogged the single hardware thread for several seconds, the application would not execute during those several seconds and would in effect experience a stop-the-world pause.

这对我来说在抢占式操作系统上没有意义。我的假设是 CMS 有一个或多个收集器线程正在运行。另一个假设是，我们讨论的是让应用程序线程将其逻辑与 GC 逻辑交错(时间复用)，而不是让 CMS 拥有专用的 GC 线程来执行垃圾收集。

是这样的吗？我在这里犯了什么错误？

谢谢

Answer 1

在 HotSpot JVM 中，垃圾收集器(包括 CMS 和 i-CMS)使用专用工作线程。

CMS 线程与应用程序线程同时运行，但它们有 higher priority :NearMaxPriority。在单核机器上，CMS 循环确实会使应用程序线程匮乏。 CMS增量模式的思想是让GC自愿将CPU让给应用程序，而不依赖操作系统调度程序。

来自HotSpot GC Tuning Guide :

Normally, the CMS collector uses one or more processors during the entire concurrent tracing phase, without voluntarily relinquishing them. Similarly, one processor is used for the entire concurrent sweep phase, again without relinquishing it. This overhead can be too much of a disruption for applications with response time constraints that might otherwise have used the processing cores, particularly when run on systems with just one or two processors. Incremental mode solves this problem by breaking up the concurrent phases into short bursts of activity, which are scheduled to occur midway between minor pauses.

注意CMS增量模式was deprecated很久以前，2012 年。