Back to back Full Garbage collections when conditions for Full GC do not seem met

[Alex Aisinzon]

Hi all

 

A customer of ours is experiencing instances whereby the Sun JDK
1.4.2_16 on Windows goes through many Full GCs for no good reason. 

The Sun JDK parameters used are: -Xms1280m -Xmx1280m -XX:NewSize=500m
-XX:MaxNewSize=500m -XX:PermSize=150m -XX:MaxPermSize=150m -server
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

I have enclosed a snippet of the garbage collection logs with minor GC
before and after (ProblematicFullGC.zip).

>From timestamp 21928.044 to 21958.226 + 5 seconds aka 35 seconds, the
JVM goes through 8 Full GCs with hardly any time in between.

To the users, the JVM is frozen. The JVM needs to get restarted to get
back to a good state.

The most surprising is that the new generation is almost empty (1 or 2
MB max used out of 460MB) in all but the first Full GC and that there is
a lot of free space in the tenured generation (more than 400MB).

Our thinking is that the JVM may be triggering a Full GC because of the
"Young Generation Guarantee".

If such is the case, the behaviour is not consistent across platforms:
we have run a similar load test in house with Sun JDK 1.4.2_16 on Linux
with the identical parameters ("-server -Xms1280m -Xmx1280m
-XX:NewSize=500m -XX:MaxNewSize=500m -XX:PermSize=150m
-XX:MaxPermSize=150m -XX:+PrintGCDetails -XX:+PrintHeapAtGC
-XX:+PrintGCTimeStamps -verbose:gc". In that case, the Full GCs occur
very normally though the tenured space is much fuller (140-180MB free
only). A snippet of the GC logs is enclosed at OKGC.zip. It shows
several Full GCs with a healthy dose of minor GC in between.

 

So far, we have recommended to the customer that they use a smaller New
Generation, as this may make it less likely to get closer to the "Young
Generation Guarantee" threshold. Nevertheless, as the math is not there
for that "Young Generation Guarantee", we want to dig further into this.

 

Thanks in advance for any help.

 

Alex Aisinzon

 

 

 

  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080212/4b42655c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProblematicFullGC.zip
Type: application/x-zip-compressed
Size: 1187 bytes
Desc: ProblematicFullGC.zip
Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080212/4b42655c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OKGC.zip
Type: application/x-zip-compressed
Size: 14900 bytes
Desc: OKGC.zip
Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080212/4b42655c/attachment-0001.bin