ParNew - how does it decide if Full GC is needed

[Vitaly Davidovich]

I'm sure jmap wasn't run at this time.  jstat reports last gc reason as
allocation failure as well, although that's secondary.

Right, I'm just as puzzled as to why a full gc occurred given that eden
opened up again after the young collection.  Only thing I can think of is
either (a) gc decides on whether to do a full collection before reclaiming
eden and thus is paranoid given the imbalance in size between eden and
tenured or (b) it panics that after promotion tenured is nearly 100% full
and decides to proactively collect it.

Would be nice to figure out exactly what the gc is thinking here; I can
then figure out the proper tuning approach.

Sent from my phone
On May 7, 2014 8:46 PM, "Matt Miller" <matthew.miller at forgerock.com> wrote:

>  Are you sure you didn't run a jmap to get a histogram or a heap dump at
> this time?
> A full GC with the tenured space that wide open doesn't make much sense
> otherwise.
>
> When you take a histogram or heap dump, the GC log doesn't tell you. I
> think it should, but others have said that this is the expected behavior.
> I'd much rather it be like a System.gc() which prints (System) in the GC Log
>
> -Matt
>
> On 5/7/14, 7:34 PM, Vitaly Davidovich wrote:
>
> 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
>
>
> _______________________________________________
> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140507/3e317c01/attachment-0001.html>