Question regarding G1 option to run parallel Old generation garbage collection?

Vitaly Davidovich vitalyd at gmail.com
Thu Oct 25 21:36:40 UTC 2012


Hmm, collecting old gen usually involves more work than doing young GC
since it may do additional things (e.g. ref processing) as well as being
larger than eden.  I think even with concurrent old you probably don't want
to trigger them due to premature promotion (if it's a non-compacting
concurrent GC, like CMS, you may start accumulating fragmentation where you
otherwise wouldn't).  Generally, it makes sense to me to have some
buffering in eden to avoid midlife crisis objects wreaking havoc in old gen.

Sent from my phone
On Oct 25, 2012 5:28 PM, "Bernd Eckenfels" <bernd-2012 at eckenfels.net> wrote:

> Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich <vitalyd at gmail.com>:
>
>  You don't want to tenure them prematurely if they ultimately
>> would die fairly soon but you can't keep them in place if you're
>> employing a copying collector.
>>
>
> Actually you might want to tenure them "early": if your oldgen is
> collected concurrently _and_ the young collection frequency is larger than
> a typical transaction (which is a fairly common situation).
>
> Therefore there is an argument for using MaxTenuring=0 (or only 1). But
> thats not really G1 related, I just wanted to mention it.
>
> Bernd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121025/b72e913a/attachment.htm>


More information about the hotspot-gc-dev mailing list