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

Alex Aisinzon aaisinzon at guidewire.com
Wed Feb 13 19:00:54 UTC 2008


Jon

The first message did go through. 
The customer changed some JVM tunings, which led the JVM to use parallel
young generation and serial collector for the tenured old.
The issue still occurrs (snippet enclosed).
I am going to follow your recommendation about contact Sun Support.
I fully understand that you worked on JDK 1.5 and 1.6 and that you are
not so familiar with 1.4.2.
I am already amazed at the level of assistance provided through the
mailing list.

Thanks again for all the help provided.

Regards

Alex A

-----Original Message-----
From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM] 
Sent: Wednesday, February 13, 2008 6:19 AM
To: Alex Aisinzon
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Back to back Full Garbage collections when conditions for
Full GCdo not seem met

RESEND:  Sorry if this is a duplicate.  I got a warning that the 
original message could
not be sent.

Alex,

Much of this information is in

http://java.sun.com/docs/hotspot/gc1.4.2/

In your logs

"def new generation"  implies the serial collector of the young
generation

"tenured generation" implies  the serial collector of the tenured
generation

"PSYoungGen" implies the parallel young generation collector for
UseParallelGC

"PSOldGen" implies the serial collector for the tenured generation
(basically the
same as "tenured generation"

UseParallelOldGC is not implemented in 1.4.2 so you won't see it.

Comments below.


Alex Aisinzon wrote:
> Jon
>
> The theory that the customer was using the client mode seems not to be
> true.
> We realize that some nodes were using client and some other were using
> server but that the excessive Full GC seems to happen also on the JVMs
> using the server mode.
>   

It would be useful to know if the excessive full GC's are occuring with
the
UseParallelGC collector ("PSYoungGen" and "PSOldGen" in the logs). 

I also think (as you have suggested) that the size
 of the young gen (500m) is too large for the
size of the tenured generation and the amount of live data
in the tenured generation (the amount of free space is
approaching the size of the young gen).  Do try a smaller
young gen or larger  overall heap.

It looks like only full collections are being attempted.  I don't
recall anything that would cause this type of behavior.
If you have a Sun support contract,  request some help on this.
The support organization is more familar with the current
behavior of  the earlier releases (i.e., what bugs have been fixed
and what enhancements have been made) and might be able to
help.


> The point about the usage of different GC policies is interesting
> though:
> Could you share with me the GC log pattern to GC policy mapping?
> In other words, as you indicate in your blog
> (http://blogs.sun.com/jonthecollector/), there are 3 young generation
> collectors and 3 tenured generation ones.
> When I look at some GC logs, how can I deduce which you and tenured
> generation collectors are used?
>
> Thanks again for the tremendous help provided here.
>
> Regards
>
> Alex A
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProblematicGC.zip
Type: application/x-zip-compressed
Size: 1168 bytes
Desc: ProblematicGC.zip
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20080213/29d16e2e/ProblematicGC.zip>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


More information about the hotspot-gc-dev mailing list