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

[Kirk Pepperdine]

+1

As I stated, a very common problem is survivor to small hence premature promotion causing too frequent Full GCs or a very busy CMS cycle typically ending badly with concurrent mode failures.

Regards,
Kirk

On 2012-10-25, at 11: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/20121026/33c4f671/attachment.htm>