JDK 5.0 Native Heap Issues?

[Keith Holdaway]

Hi,

We have been running an endurance test suite with LoadRunner against JDK 5.0 u14 with the following VM arguments:

et JAVA_OPTS=%JAVA_OPTS% -Xms1000m -Xmx1000m -XX:PermSize=87m -XX:MaxPermSize=87m -Xss96k -XX:-UseTLAB -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:NewSize=128m -XX:MaxNewSize=128m -Dcom.sun.management.jmxremote -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true -Dsas.svcs.http.max.connections=50

And we keep seeing the following error message after 15 hours:

Exception java.lang.OutOfMemoryError: requested 655360 bytes for GrET* in C:/BUILD_AREA/jdk1.5.0_15/hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?

I suggested that this error is the result of native heap issues - fragmentation perhaps, and so reducing the -Xmx and -Xss and MaxPermGen would enable more native heap. This is a 32 bit Windows box, and the /3GB switch is turned on.

The tester has added the following two VM args to enable an improvement in CMS usage, since it seems our application allocates at such a rate that CMS is overrun and Full GCs interrupt the CMS algorithm:

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=40

But he also changed the JDK to 6.0 u7, and now the endurance test has run for 25 hrs?

We are not sure if the success is contributed to JDK6 or to -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=40

Any ideas?

Also, is the -XX:+UseCMSCompactAtFullCollection a default behaviour for JDK 5.0?

thanks

keith
_
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use