ParNew - how does it decide if Full GC is needed

[Vitaly Davidovich]

Actually, one thing I just thought of is we force a couple of gc's at
startup time (to reclaim garbage generated during init) and if that causes
premature promotion to tenured space (again, not sure why that would be
given we use default tenuring threshold of 7) then perhaps we hit a
promotion failure during this real GC since old gen capacity is not large
enough.

However, I'd still appreciate it if someone could shed some light on any
other possibilities here.  I should also mention that I checked perm gen
and direct mem usage (I.e. direct byte bufs) and neither one appears to be
a suspect.

Sent from my phone
On May 7, 2014 9:01 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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/0d35e97d/attachment.html>