ParNew - how does it decide if Full GC is needed

[Vitaly Davidovich]

We're using parallel scavenge, not ParNew.  I mentioned ParNew a few times
in this thread only because it doesn't attempt to do a full gc preemptively
(based on what Jon said) like PS, and thought maybe it's worth a shot for
our usecase.  But it's PS that started this thread ...

Thanks

Sent from my phone
On May 9, 2014 4:39 PM, "Srinivas Ramakrishna" <ysr1729 at gmail.com> wrote:

>
> 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/4387e55b/attachment.html>