Java 8: CMS does not kick on for old generation even though CMSInitiatingOccupancyFraction specified

Question

I am running a Java WebApp using tomcat7 and JRE 1.8. The application caches huge amount of data (~15GB), and supports high throughput (~4K/sec). Due to high request rate, it generates large number of objects in the young generation, some of the objects survive the ParNew collections in young generation and are moved to survivor and eventually to old generation space in the heap memory.

These objects keep getting accumulated in the old generation. CMS kicks in when the old generation is almost full, and that results into stop-the-world GC. This affects the latencies of my application.

To avoid this, I started using CMSInitiatingOccupancyFraction=85 along with +UseCMSInitiatingOccupancyOnly. However, in spite of these two options, CMS does not kick in when old generation is 85% full. It still happens when the old generation is almost full and does a stop-the-world GC. I searched for limitations of CMSInitiatingOccupancyFraction, but could not find any relevant link explaining the behavior. Please find below the exact command line for my tomcat process:

jsvc.exec -home /usr/lib/jvm/jre1.8.0_45 -user tomcat7 \
-pidfile /home/ameya/service/2.0.4-SNAPSHOT/logs/catalina-daemon.pid \
-outfile /home/ameya/service/2.0.4-SNAPSHOT/logs/catalina-daemon.out \
-errfile &1 \
-classpath /home/ameya/conf/service:/home/ameya/service/2.0.4-SNAPSHOT/bin/bootstrap.jar:/home/ameya/service/2.0.4-SNAPSHOT/bin/commons-daemon.jar:/home/ameya/service/2.0.4-SNAPSHOT/bin/tomcat-juli.jar \
-Djava.util.logging.config.file=/home/ameya/service/2.0.4-SNAPSHOT/conf/logging.properties \
-XX:+UseConcMarkSweepGC \
-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \
-XX:+ExplicitGCInvokesConcurrent \
-Djava.awt.headless=true \
-XX:PermSize=1G \
-XX:MaxPermSize=5G \
-XX:+UseCMSInitiatingOccupancyOnly \
-XX:CMSInitiatingOccupancyFraction=85 \
-Xms12G -Xmx24G \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9004 \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-Duser.language=en \
-Duser.country=US \
-Dsun.net.inetaddr.ttl=30 \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/tmp/dump.tmp \
-XX:+AggressiveOpts \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
-Djava.endorsed.dirs= \
-Dcatalina.base=/home/ameya/service/2.0.4-SNAPSHOT \
-Dcatalina.home=/home/ameya/service/2.0.4-SNAPSHOT \
-Djava.io.tmpdir=/home/ameya/service/2.0.4-SNAPSHOT/temp \
org.apache.catalina.startup.Bootstrap

Can someone please help me understand why CMS does not start a run when the old generation is 85% full?

Answer 1

According to the oracle forums incremental CMS ignores InitiatingOccupancyFraction.

iCMS also is deprecated and will be removed in openjdk 9. And doesn't make much sense on a server machine since it was mostly meant for applications that run on processors with one or two cores.