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

[charlie hunt]

I think others are benefiting from your question(s) … and it’s helping refresh my memory of things too. ;-)

Actually, I just looked at what we documented in Java Performance Companion for G1ReservePercent, this wording may imply a very slightly subtle different definition, “To reduce the risk of getting a promotion failure, G1 reserves some memory for promotions. This memory will not be used for the young generation.” 

Perhaps one of the G1 engineers can clarify this?

Based on what we documented for G1ReservePercent, it implies that regions are reserved for promotions, which implies old generation regions. Note that on a young GC, some objects will be evacuated to survivor regions, and if G1 decides to grow the number of eden regions, then both those evacuated “to survivor regions” and “additional eden regions” will not come from that G1ReservePercent. And, since humongous objects are allocated from old regions, it is not clear to me that G1ReservePercent regions could be allocated into as humongous objects if the intent for G1ReservePercent is for promotions. Humongous objects are not promoted. They are allocated directly into humongous regions which get allocated from old generation.

Again, hopefully one of the G1 engineers can jump in and clarify.

Thanks for the question(s)!

charlie 

> On Oct 7, 2016, at 12:09 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> 
> 
> On Fri, Oct 7, 2016 at 1:00 PM, charlie hunt <charlie.hunt at oracle.com <mailto:charlie.hunt at oracle.com>> wrote:
> Glad to hear you’re not confused with the terminology.  :-)
> 
> On ReservePercent, my understanding is that the ReservePercent applies to the number of regions that will not used for young generation, eden regions or survivor regions. The intent is avoid to-space exhausted by ensuring a “reserved percentage” of regions are available for evacuation. This implies that those reserved regions could be used for old regions or humongous regions.
> Ok, so then the more explicit wording would be "The intent is to avoid to-space exhausted by ensuring a reserved percentage of regions are available for evacuation or humongous object allocation", right? Perhaps the "for evacuation" is throwing it off a bit for me, since the HO allocation isn't an "evacuation" obviously. 
> 
> Thanks Charlie
> 
> P.S. I realize I'm hijacking Prasanna's thread quite a bit, but hopefully the discussed info is useful anyway.
> 
> charlie
> 
>> On Oct 7, 2016, at 11:51 AM, Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> 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 <http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use>
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20161007/b5ef7cd5/attachment.html>