CMS垃圾收集器 - 它何时运行？ [英] CMS garbage collector - when does it run?

问题描述

MaxHeapFreeRatio （70）我对两个可能控制的参数感到困惑。

CMSInitiatingOccupancyFraction （默认超过90％）

这些参数中的每一个意味着什么？什么时候收集器开始（标记阶段）和收集（清扫阶段）？ 解决方案CMSInitiatingOccupancyFraction决定CMS何时开始（为了使此选项有效，您还必须设置XX：+ UseCMSInitiatingOccupancyOnly）。 MaxHeapFreeRatio是一个选择大小世代空间的选项。

例如...

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

并发收集通常无法加速，但可以更早启动。
当旧代中分配空间的百分比超过阈值时，并发收集开始运行。该阈值是基于并发收集器的一般经验计算的。如果发生完整收集，可能需要更早启动并发收集。命令行标志CMSInitiatingOccupancyFraction可用于设置集合开始的级别。其默认值约为68％。调整值的命令行是
-XX：CMSInitiatingOccupancyFraction =

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

默认情况下，虚拟机会在每个集合上增大或缩小堆，以尝试在特定范围内的每个集合中保留可用空间与活动对象的比例。该目标范围由参数-XX：MinHeapFreeRatio =和-XX：MaxHeapFreeRatio =设置为百分比，并且总大小由-Xms限定在以下，并且由-Xmx限定。此表中显示了32位Solaris操作系统（SPARC平台版）的默认参数：

..或..

http://www.petefreitag.com/articles/gctuning/

-XX：MaxHeapFreeRatio - 当一代中可用空间的百分比超过此值时，代将收缩以达到此值。默认是70

编辑：我用一个测试程序运行了一些模拟程序，它随机创建字节数组映射并复制它们。我注意到a）分数值没有得到尊重 - 特别是保守值（比如说50），CMS初始标记阶段的入住率超过了50％，一般在70-80％左右，b）尽管如此，较小的分数值使CMS
（使用的程序-Xmx1536m -Xmx1536m -XX：NewSize = 512m -XX：+ UseConcMarkSweepGc + gc logging以及两个测试参数）

我还发现了一个关于此的旧bug报告： http：//bugs.sun .com / bugdatabase / view_bug.do？bug_id = 6486089

I am confused about two parameters that may control when the CMS collector kicks in:

MaxHeapFreeRatio (70% by default)

CMSInitiatingOccupancyFraction (over 90% by default)

What does each of those parameters mean, exactly? When does the collector start (the marking phase), and collect (the sweeping phase)?

解决方案

CMSInitiatingOccupancyFraction decides when the CMS kicks in (in order for this option to be effective you must also set XX:+UseCMSInitiatingOccupancyOnly ). MaxHeapFreeRatio is an option to size the generational spaces.

See for example ...

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

The concurrent collection generally cannot be sped up but it can be started earlier. A concurrent collection starts running when the percentage of allocated space in the old generation crosses a threshold. This threshold is calculated based on general experience with the concurrent collector. If full collections are occurring, the concurrent collections may need to be started earlier. The command line flag CMSInitiatingOccupancyFraction can be used to set the level at which the collection is started. Its default value is approximately 68%. The command line to adjust the value is -XX:CMSInitiatingOccupancyFraction=

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. This target range is set as a percentage by the parameters -XX:MinHeapFreeRatio= and -XX:MaxHeapFreeRatio=, and the total size is bounded below by -Xms and above by -Xmx . The default parameters for the 32-bit Solaris Operating System (SPARC Platform Edition) are shown in this table:

.. or ..

http://www.petefreitag.com/articles/gctuning/

-XX:MaxHeapFreeRatio - when the percentage of free space in a generation exceeded this value the generation will shrink to meet this value. Default is 70

EDIT : I ran a few simulations with a test program that just randomly creates maps of byte arrays and copies them around. I noticed that a) fraction value was not respected - in particular with a conservative value (say 50) the CMS initial mark stage kicked in much beyond 50% occupancy, typically around 70-80% and b) nonetheless smaller fraction values made the CMS initial stage happen earlier (program used -Xmx1536m -Xmx1536m -XX:NewSize=512m -XX:+UseConcMarkSweepGc + gc logging and the two test parameters)

I've also found an old bug report regarding this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089

这篇关于CMS垃圾收集器 - 它何时运行？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！