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

Srinivas Ramakrishna ysr1729 at gmail.com
Fri Oct 26 01:15:40 UTC 2012


Vitaly is exactly correct. In my own experience, even for cases of the kind
that Bernd is describing, I have always found MTT=1 to be superior to
MTT=0, because the cost of promoting objects prematurely can wreak havoc,
especially with certain kinds of data structures such as long lists (at
least as long as old gens are much larger and old gen collections much more
expensive than young gen ones).

-- ramki

On Thu, Oct 25, 2012 at 2:36 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> 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/ddbb951c/attachment.htm>


More information about the hotspot-gc-dev mailing list