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

Sat Oct 8 18:30:53 UTC 2016

On Friday, October 7, 2016, Gopal, Prasanna CWK <
prasanna.gopal at blackrock.com
<javascript:_e(%7B%7D,'cvml','prasanna.gopal at blackrock.com');>> wrote:

> Hi All
>
>
>
>
>
> Thanks for all your reply. These discussions certainly help to get good
> insight J.
>
>
>
> So just to summarize
>
>
>
> 1)     G1ReservePercent will not affect Humongus allocation , so the full
> GC we are encountering is due to fragmentation
>
> It may or may not - let's see what a G1 dev says (as Jenny mentioned).
Either way, you don't have enough contiguous regions to satisfy the
allocation, so it's fragmentation one way or the other.

You should drop G1ReservePercent for now unless you have good reason for
setting it to 40 (that's a large value, btw).

> 2)     I will try chaging G1MixedGCLiveThresholdPercent to 85 to see the
> mixed GC’s can be increased.
>
Yes, that's a good idea.  Do you see any mixed GCs at all now? If so, how
long are the concurrent marking phases taking (look for concurrent-mark-end
in the gc log).

> 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
>
Have you tried just setting Xmx and a reasonable pause time goal? As a rule
of thumb, setting Xmx to 3x your live set works well (the more headroom you
give to G1, the better).  Giving it a reasonable pause time goal allows it
to adjust young gen dynamically and possibly raising it high enough such
that there's either no promotion or very little - young gen collection
efficiency is a function of how many survivors you have when the collection
kicks in, so the fewer survivors the better (that applies to all
generational copying collectors, not just G1 of course).

>
>
> 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 <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>
> 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> wrote:
>
>
>
> Hi Jenny,
>
>
>
> On Fri, Oct 7, 2016 at 11:52 AM, yu.zhang at oracle.com <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
> 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/corpo
> rate/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.
>
>

-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20161008/851f9dc5/attachment-0001.html>