G1-GC - Full GC [humongous allocation request failed]
Vitaly Davidovich
vitalyd at gmail.com
Fri Oct 7 17:44:29 UTC 2016
On Friday, October 7, 2016, charlie hunt <charlie.hunt at oracle.com> wrote:
> 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?
>
Yeah, would be good to clarify. The above wording in the performance
companion is at odds of other definitions. If the regions can be used to
hold Eden survivors or other survivors from existing survivor regions, then
it's not really accurate to say it's not used for the young generation.
I'm guessing what's meant is it won't be used for Eden regions, i.e. to
hold normal non HO allocations.
>
> 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.
>
It seems they're reserved for evacuees, not promotions, which can come from
any region modulo humongous (since those aren't copied).
>
> Again, hopefully one of the G1 engineers can jump in and clarify.
>
Yes, please.
>
> Thanks for the question(s)!
>
> charlie
>
> On Oct 7, 2016, at 12:09 PM, Vitaly Davidovich <vitalyd at gmail.com
> <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com');>> wrote:
>
>
>
> On Fri, Oct 7, 2016 at 1:00 PM, charlie hunt <charlie.hunt at oracle.com
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com');>> wrote:
>>
>> Hi Charlie,
>>
>> On Fri, Oct 7, 2016 at 12:46 PM, charlie hunt <charlie.hunt at oracle.com
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com');>> wrote:
>>>
>>> Hi Jenny,
>>>
>>> On Fri, Oct 7, 2016 at 11:52 AM, yu.zhang at oracle.com
>>> <javascript:_e(%7B%7D,'cvml','yu.zhang at oracle.com');> <
>>> yu.zhang at oracle.com
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','hotspot-gc-use at openjdk.java.net');>
>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>
>>>
>>>
>>
>>
>
>
--
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20161007/61131d41/attachment-0001.html>
More information about the hotspot-gc-use
mailing list