Java HotSpot Virtual Machine

Hi all,

I have an issue where the CMS garbage collector is not executing, and I wonder if someone can clue me in on what could possibly cause such behavior. I'm running my program (using java 1.6.0_29) with the following JVM parameters:

CATALINA_OPTS="-d64 -server -Xmx4g -Xms4g -XX:MaxPermSize=128m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewSize=512m -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:PrintCMSStatistics=3 -XX:+PrintCMSInitiationStatistics -XX:+PrintAdaptiveSizePolicy -XX:+PrintCompilation -XX:+PrintConcurrentLocks -XX:+PrintGCTaskTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintSharedSpaces -XX:+PrintTenuringDistribution -XX:+PrintVMQWaitTime -Xloggc:/dpz/ems-ws/bin/gc.log -verbose:gc"

In my gc.log file, I see the following CMS Entries:

2011-11-14T09:47:24.660-0500: 1104.878: [GC [1 CMS-initial-mark: 2758057K(3670016K)] 2796390K(4141888K), 0.0550771 secs] [Times: user=0.02 sys=0.03, real=0.06 secs]
Total time for which application threads were stopped: 0.0711610 seconds
2011-11-14T09:47:24.718-0500: 1104.936: [CMS-concurrent-mark-start]

So it looks like the CMS initiated. However, that's the last I ever heard from it. Memory kept expanding for the next 15 minutes or so until the heap was completely full, at which time the app hung on the following statement:

2011-11-14T10:01:18.041-0500: 1939.377: [GC 1939.377: [ParNew: 471872K->471872K(471872K), 0.0000399 secs]1939.377: [CMS

for many minutes until I finally just killed the JVM. So that last statement seems to indicate that the CMS wanted to do something...but at this point it was kinda too late.


If I change -XX:CMSInitiatingOccupancyFraction=75 to -XX:CMSInitiatingOccupancyFraction=30, this seems to work. However, I don't understand why.

Note that my program is running a Berkeley DB which I am giving 60% of the JVM memory to for cache. Thus, after a warmup period, 60% of the total heap will always be considered "live" for the cache alone.