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

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