G1-GC - Full GC [humongous allocation request failed]

Fri Oct 7 17:29:44 UTC 2016

Hi All

Thanks for all your reply. These discussions certainly help to get good insight ☺.

So just to summarize

1)     G1ReservePercent will not affect Humongus allocation , so the full GC we are encountering is due to fragmentation

2)     I will try chaging G1MixedGCLiveThresholdPercent to 85 to see the mixed GC’s can be increased.

3)     Due to some other dependencies , we were unable to move to latest Jdk’s ( Jdk 8).  Our application is currently running with CMS and we are seeing long GC pause , that why we wanted to explore G1.As we can’t move Jdk 8 soon , Is it good idea to migrate to G1 with Jdk 7

Thanks and regards
Prasanna

From: hotspot-gc-use [mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Vitaly Davidovich
Sent: 07 October 2016 18:27
To: yu.zhang at oracle.com
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: G1-GC - Full GC [humongous allocation request failed]

Hi Jenny,

On Fri, Oct 7, 2016 at 1:15 PM, yu.zhang at oracle.com<mailto:yu.zhang at oracle.com> <yu.zhang at oracle.com<mailto:yu.zhang at oracle.com>> wrote:

Hi, Vitaly,

Here is what happens in jdk9(I think the logic is the same as in jdk8).
_reserve_regions = reserve percent*regions of the heap
when trying to decide regions for young gen, we look at the free regions at the end of the collection, and try to honor the reserve_regions
if (available_free_regions > _reserve_regions) {
    base_free_regions = available_free_regions - _reserve_regions;
}

And there are other constrains to consider: user defined constrains and pause time goal.

This is what I meant by 'try to honor' the reserved.
If there is enough available_free_regions, it will reserve those regions. Those regions can be used as old or young.
Ok, thanks.  As you say, G1 *tries* to honor it, but may not.  The docs I've come across online make it sound like this reservation is a guarantee, or at least they don't stipulate the reservation may not work.  I don't know if it's worth clarifying that point or not, but my vote would be to make the docs err on the side of "more info" than less.

The second part is what I mentioned to Charlie in my last reply - can humongous *allocations* be satisfied out of the reserve, or are the reserved regions only used to hold evacuees (when base_free_regions are not available).

Thanks

Jenny

On 10/07/2016 09:51 AM, Vitaly Davidovich wrote:
Hi Charlie,

On Fri, Oct 7, 2016 at 12:46 PM, charlie hunt <charlie.hunt at oracle.com<mailto:charlie.hunt at oracle.com>> wrote:
Hi Vitaly,

Just to clarify things in case there might be some confusion … one of the terms in G1 can be a little confusing with a term used in Parallel GC, Serial GC and CMS GC, and that is “to-space”.  In the latter case, “to-space” is a survivor space. In G1, “to-space” is any space that a G1 is evacuating objects too.  So a “to-space exhausted” means that during an evacuation of live objects from a G1 region (which could be an eden region, survivor region or old region), and there is not an available region to evacuate those live objects, this constitutes a “to-space failure”.

I may be wrong, but my understanding is that once a humongous object is allocated, it is not evacuated. It stays in the same allocated region(s) until it is marked as being unreachable and can be reclaimed.
Right, I understand the distinction in terminology.

What I'm a bit confused by is when Jenny said "I agree the ReservePercent=40 is too high, but that should not prevent allocating to the old gen. G1 tries to honor ReservePercent."  Specifically, the "G1 tries to honor ReservePercent".  It wasn't clear to me whether that implies humongous allocations can look for contiguous regions in the reserve, or not.  That's what I'm hoping to get clarification on since other sources online don't mention G1ReservePercent playing a role for HO specifically.

Thanks

charlie

On Oct 7, 2016, at 11:00 AM, Vitaly Davidovich <vitalyd at gmail.com<mailto:vitalyd at gmail.com>> wrote:

Hi Jenny,

On Fri, Oct 7, 2016 at 11:52 AM, yu.zhang at oracle.com<mailto:yu.zhang at oracle.com> <yu.zhang at oracle.com<mailto:yu.zhang at oracle.com>> wrote:

Prasanna,

In addition to what Vitaly said, I have some comments about your question:

1)      Humongus allocation request for 72 mb failed, from the logs we can also see we have free space of  around 3 GB. Does this means , our application is encountering high  amount of fragmentation ?.

It is possible. What it means is g1 can not find 36 consecutive regions for that 72 mb object.

I agree the ReservePercent=40 is too high, but that should not prevent allocating to the old gen. G1 tries to honor ReservePercent.
So just to clarify - is the space (i.e. regions) reserved by G1ReservePercent allocatable to humongous object allocations? All docs/webpages I found talk about this space being for holding survivors (i.e. evac failure/to-space exhaustion mitigation).  It sounds like you're saying these reserved regions should also be used to satisfy HO allocs?

Thanks
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net<mailto:hotspot-gc-use at openjdk.java.net>
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use<https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_mailman_listinfo_hotspot-2Dgc-2Duse&d=DQMFaQ&c=zUO0BtkCe66yJvAZ4cAvZg&r=zRhnqN6xuCQh8NZ-MtoiYBMlItU6r8UBO9AjZ3c3DEY&m=bFLMKO8nyTpNvz4kdxHMZYhhI0bhpuK8D-VzwdSucAs&s=OYJg7JMU45EUL_dJoLlr5CPanO_joIXi1r8LfuSxZcY&e=>

This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.blackrock.com/corporate/en-us/compliance/email-disclaimers for further information.  Please refer to http://www.blackrock.com/corporate/en-us/compliance/privacy-policy for more information about BlackRock’s Privacy Policy.
BlackRock Advisors (UK) Limited and BlackRock Investment Management (UK) Limited are authorised and regulated by the Financial Conduct Authority. Registered in England No. 796793 and No. 2020394 respectively. BlackRock Life Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Registered in England No. 2223202. Registered Offices: 12 Throgmorton Avenue, London EC2N 2DL. BlackRock International Limited is authorised and regulated by the Financial Conduct Authority and is a registered investment adviser with the Securities and Exchange Commission (SEC). Registered in Scotland No. SC160821. Registered Office: Exchange Place One, 1 Semple Street, Edinburgh EH3 8BL.
For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/en-us/about-us/contacts-locations.

© 2016 BlackRock, Inc. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20161007/08cee811/attachment.html>