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

[Vitaly Davidovich]

On Fri, Oct 7, 2016 at 1:00 PM, charlie hunt <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> 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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20161007/2268179c/attachment-0001.html>