ParNew - how does it decide if Full GC is needed

[Srinivas Ramakrishna]

Hi Peter --

On Fri, May 9, 2014 at 11:01 AM, Peter B. Kessler <
Peter.B.Kessler at oracle.com> wrote:

> On 05/08/14 18:04, Vitaly Davidovich wrote:
>
>> Thanks Peter, I understand the mess that a promotion failure causes now.
>>  I'm interested in your opinion on Ramki's last point, which is to defer
>> the full gc until the next scavenge (I.e. remember that you think you may
>> have promotion failure on next scavenge, and then do a full gc right before
>> that next scavenge).
>>
>
> The algorithm used for a full collection is not well-suited for a heap in
> which there's a lot of garbage.  It involves (at least) two passes: an
> object-graph-order marking pass to identify live objects, and then an
> address-order pass that looks at every object and moves it if it is live
> (for the compacting collectiors), or puts it on a free-list if it isn't
> (for the non-moving collectors).  In contrast, scavenging is a single
> object-graph-order pass that examines only the live objects.  That's why it
> is such a win for edens where we expect the garbage ratio to be high.
>
> Time a young generation collection on a typical 10GB eden, and one on a
> similarly-populated 10GB old generation.  For science!
>

Thanks for that crucial reminder. Indeed in the case of the ParNew
collector that Vitaly appears to be using (why? if you don't use CMS in the
old gen?), doing a successful parallel scavenge versus a slow serial
compaction that includes those passes serially over an Eden that is full of
garbage is even more stark than in the case of the parallel old collector
where at least portions of those passes are done multi-threaded.

-- ramki


> If we wait until the eden is full again, when we know the old generation
> is also full, then we can't scavenge the young generation.  Maybe that
> wouldn't bother you because you are hoping there is no next collection.
>  You've chosen to use the throughput collector, where the focus is on
> getting the collections done in the most efficient manner.  Ramki is
> suggesting the low-pause collector, where the focus is on doing most of the
> collection work concurrent with application work.  If there are cycles to
> spare (CPU and memory) that might complete a full collection without
> interfering with the application, so maybe Ramki is not as concerned about
> cost of a failed promotion and full collection.  One size does not fit all.
>  You haven't said why you made the choice you did.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140509/57e5cc9f/attachment.html>