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

[charlie hunt]

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.

charlie

> On Oct 7, 2016, at 11:51 AM, Vitaly Davidovich <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/3b19c491/attachment.html>