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 <vita...@gmail.com> 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
