On Fri, Oct 7, 2016 at 1:00 PM, charlie hunt <charlie.h...@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 <vita...@gmail.com> wrote: > > Hi Charlie, > > On Fri, Oct 7, 2016 at 12:46 PM, charlie hunt <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> wrote: >> >> Hi Jenny, >> >> On Fri, Oct 7, 2016 at 11:52 AM, yu.zh...@oracle.com <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 >> 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
