CMS garbage collector - when does it run?

Question

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

Palaeozoology

Answer 1

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=<percent>

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=<minimum> and -XX:MaxHeapFreeRatio=<maximum>, and the total size is bounded below by -Xms and above by -Xmx.

.. 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: https://bugs.java.com/bugdatabase/view_bug?bug_id=6486089

Myall

CMSInitiatingOccupancyFraction is only used for the 1st collection unless -XX:+UseCMSInitiatingOccupancyOnly is set. If you don't set the latter switch then, after the first one, the usual heuristics (which are based on allocation stats gathered during runtime) are used to determine when CMS starts. – Wellfed

From some observation it seems like after a few night hours of low usage it did not kick in until it reached over 90% (that is CMSInitiatingOccupancy. However, during the day it does not seem to wait as long but collects sooner. This seems to correspond to what @Wellfed said, but in this case I would like to know what "the usual heuristics" are and how long a peace time makes it go dormant and wait for the >90% threshold. – Palaeozoology

Not having had this issue myself, my understanding is that when you have XX:+UseCMSInitiatingOccupancyOnly set the JVM should respect the value set in CMSInitiatingOccupancyFraction. If you don't have UseCMSInitiatingOccupancyOnly the JVM has some wiggle room. – Myall

the decision to start the tenured collection is based on previous collection times and how long it has taken tenured to fill up in the past. If it knows it normally takes a minute to complete a cycle and it takes a minute to move from 80% to full then it will aim to start when occupancy is rather less than 80%. I believe this decision is also influenced by the level of fragmentation in tenured (since CMS is not a copying collector, it suffers from fragmentation and therefore the potential need for a full STW compacting collection) – Wellfed