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.
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.h...@oracle.com
<mailto:charlie.h...@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 <vita...@gmail.com
<mailto:vita...@gmail.com>> wrote:
Hi Jenny,
On Fri, Oct 7, 2016 at 11:52 AM, yu.zh...@oracle.com
<mailto:yu.zh...@oracle.com> <yu.zh...@oracle.com
<mailto:yu.zh...@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@openjdk.java.net
<mailto:hotspot-gc-use@openjdk.java.net>
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
<http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use>
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
