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)?
The CMS collector attempts to reduce pause times due to major collections by using separate garbage collector threads to trace the reachable objects concurrently with the execution of the application threads.
In Java, garbage collection happens automatically during the lifetime of a program. This eliminates the need to de-allocate memory and therefore avoids memory leaks. Java Garbage Collection is the process by which Java programs perform automatic memory management.
When a JVM runs out of space in the storage heap and is unable to allocate any more objects (an allocation failure), a garbage collection is triggered. The Garbage Collector cleans up objects in the storage heap that are no longer being referenced by applications and frees some of the space.
The more live objects are found, the longer the suspension, which has a direct impact on response time and throughput. This fundamental tenet of garbage collection and the resulting effect on application execution is called the garbage-collection pause or GC pause time.
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: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With