ParNew - how does it decide if Full GC is needed

[Vitaly Davidovich]

Hi Jon,

Nope, we're not using CMS here; this is the throughput/parallel collector
setup.

I was browsing some of the gc code in openjdk, and noticed a few places
where each generation attempts to decide (upfront from what I can tell,
i.e. before doing the collection) whether it thinks it's "safe" to perform
the collection (and if it's not, it punts to the next generation) and also
whether some amount of promoted bytes will fit.

I didn't dig too much yet, but a cursory scan of that code leads me to
think that perhaps the defNew generation is asking the next gen (i.e.
tenured) whether it could handle some estimated promotion amount, and given
the large imbalance between Young and Tenured size, tenured is reporting
that things won't fit -- this then causes a full gc.  Is that at all
possible from what you know?

On your first remark about compaction, just to make sure I understand,
you're saying that a full GC prefers to move all live objects into tenured
(this means taking objects out of survivor space and eden), irrespective of
whether their tenuring threshold has been exceeded? If that
compaction/migration of objects into tenured overflows tenured, then it
attempts to compact the young gen, with overflow into survivor space from
eden.  So basically, this generation knows how to perform compaction and
it's not just a copying collection?

Is there a way to get the young gen to print an age table of objects in its
survivor space? I couldn't find one, but perhaps I'm blind.

Also, as a confirmation, System.gc() always invokes a full gc with the
parallel collector, right? I believe so, but just wanted to double check
while we're on the topic.

Thanks


On Thu, May 8, 2014 at 1:39 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

>
> On 05/07/2014 05:55 PM, Vitaly Davidovich wrote:
>
> Yes, I know :) This is some cruft that needs to be cleaned up.
>
> So my suspicion is that full gc is triggered precisely because old gen
> occupancy is almost 100%, but I'd appreciate confirmation on that.  What's
> surprising is that even though old gen is almost full, young gen has lots
> of room now.  In fact, this system is restarted daily so we never see
> another young gc before the restart.
>
> The other odd observation is that survivor spaces are completely empty
> after this full gc despite tenuring threshold not being adjusted.
>
>
> The full gc algorithm used compacts everything (old gen and young gen) into
> the old gen unless it does not all fit.   If the old gen overflows, the
> young gen
> is compacted into itself.  Live in the young gen is compacted into eden
> first and
> then into the survivor spaces.
>
>  My intuitive thinking is that there was no real reason for the full gc
> to occur; whatever allocation failed in young could now succeed and
> whatever was tenured fit, albeit very tightly.
>
>
> Still puzzling about the full GC.  Are you using CMS?  If you have
> PrintGCDetails output,
> that might help.
>
> Jon
>
>  Sent from my phone
> On May 7, 2014 8:40 PM, "Bernd Eckenfels" <bernd-2014 at eckenfels.net>
> wrote:
>
>> Am Wed, 7 May 2014 19:34:20 -0400
>> schrieb Vitaly Davidovich <vitalyd at gmail.com>:
>>
>> > The vm args are:
>> >
>> > -Xms16384m -Xmx16384m -Xmn16384m -XX:NewSize=12288m
>> > -XX:MaxNewSize=12288m -XX:SurvivorRatio=10
>>
>> Hmm... you have confliciting arguments here, MaxNewSize overwrites Xmn.
>> You will get 16384-12288=4gb old size, thats quite low. As you can see
>> in your FullGC the steady state after FullGC has filled it nearly
>> completely.
>>
>> Gruss
>> Bernd
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>
>
> _______________________________________________
> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://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/20140508/bc193ee5/attachment.html>