ParNew - how does it decide if Full GC is needed

[Vitaly Davidovich]

Hi guys,

I'd like to get some clarity on exactly how ParNew GC decides whether to
follow-up a young GC with a full GC.  Here's a snippet of a young GC
followed up by full GC on jdk 7u51:

29524.949: [GC 11279905K->4112377K(15728640K), 1.6319030 secs]
29526.581: [Full GC 4112377K->4085613K(15728640K), 6.8704770 secs]

The vm args are:

-Xms16384m -Xmx16384m -Xmn16384m -XX:NewSize=12288m -XX:MaxNewSize=12288m
-XX:SurvivorRatio=10

So it's expected that most objects in the young gen will die after a young
collection, and that's the case here (~7gb collected).  We have about 4gb
survivors, which obviously overflows the two survivor spaces (they're 1gb
each).  Is the survivor space overflow the reason the full gc is initiated,
and obviously doesn't clear much (again, as expected)? It also appears that
both survivor spaces are completely empty after this full gc, whereas I'd
expect some objects to stay there and only some overflow amount would be
promoted to tenured size.

The other possible theory behind why full gc occurs in this case is that
ParNew cannot predict how much space a young gc will clear (i.e. it doesn't
know that majority will be collected) and given that tenured size is pretty
small compared to eden, it initiates a full gc.  Alternatively, since all
objects apparently got promoted to tenured after this collection (why, by
the way? we don't reduce tenuring threshold and this was only the 2nd GC of
the day) and the promoted size is something like 98% of old gen capacity,
GC panics and does a full GC in hopes of leaving itself some breathing room
in the tenured space.

Or is there something else entirely?

I'd greatly appreciate if someone could explain the above.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140507/0a888886/attachment.html>