[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-use
Subject:    Re: G1-GC - Full GC [humongous allocation request failed]
From:       Thomas Schatzl <thomas.schatzl () oracle ! com>
Date:       2016-10-11 6:55:26
Message-ID: 1476168926.2502.3.camel () oracle ! com
[Download RAW message or body]

Hi Vitaly,

On Mon, 2016-10-10 at 06:42 -0400, Vitaly Davidovich wrote:
> Hi Thomas,
> 
> Thanks for the clarification and insights.  A few comments below ...
> 
> On Monday, October 10, 2016, Thomas Schatzl <thomas.schatzl@oracle.co
> m> wrote:
> > Hi all,
> > 
> > On Fri, 2016-10-07 at 13:44 -0400, Vitaly Davidovich wrote:
> > > 
> > > On Friday, October 7, 2016, charlie hunt <charlie.hunt@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?
> >
> >   the area covered by G1ReservePercent is regular space available
> > for any allocation, whether young or old or humongous.
> > 
> > The only difference is that while the heap occupancy is beyond the
> > reserve percent threshold, young gen will be minimal (like bounded
> > by G1NewSizePercent). I.e. G1 will run in some kind of "degraded
> > throughput" mode. "Degraded" as in young gen size is typically
> > somehow correlated with allocation throughput, so if you bound
> > young gen size, you also bound throughput.
>
> Ok, so that's a quite different definition of the reserve than pretty
> much all sources that I've seen :).  Your explanation makes it sound
> like a "yellow zone" for G1, or a throttle/watermark for the young
> gen sizing.

I described the effect it has. It should be considered a reserve for
unexpected promotions/allocations only, and in general is an area to
not allocate into.

[...]
> 
> > If young gen size + old gen occupancy starts eating into area 1), 
> > G1 minimizes young gen to try to keep as much memory left for these
> > "extraneous allocations" that G1ReservePercent indicates, in the 
> > hope that the IHOP is "soon" kicking in. Until jdk9, G1 assumes 
> > that the user gave some sane settings according to (roughly) this 
> > model.
> > With jdk9 onwards, the IHOP is determined automatically according 
> > to this model and so far seems to work quite nicely - at least it 
> > will typically give you a decent starting point for setting it on 
> > your own.

> Ok, so the reserve acts like a high watermark in 9, used to adjust
> IHOP dynamically.  It sounds like it's an IHOP++ setting :).

;)

In the cases I have seen so far, the adaptive IHOP mechanism makes sure
that you don't get into this situation to actually use the reserve at
all - unless the application behavior changes a lot over time to avoid
full gc.

I am sure you can find situations where it fails of course. It is just
another heuristic.

> I'm also not sure winding the young gen down helps in cases where old
> gen occupancy is growing.  Intuitively, that ought to make things
> worse actually.  Young evacs will occur more frequently, with higher
> likelihood that more objects are still live, and need to be kept
> alive, possibly causing further promotion.

That depends on the application. Some applications work this way, many
others don't, at least beyond a certain threshold of young gen size.

There is the option to set G1ReservePercent to zero and set IHOP
manually, then the upper bound for eden is just the remaining memory in
this situation.

You could set the "confidence" the adaptive IHOP has too to get some
extra slack.

> One way that it helps is there's more frequent feedback to G1 about
> heap occupancy (since young evacs occur more frequently), and so it
> may notice that things aren't looking so peachy earlier.  Is that the
> idea?

There is the reason you suggest, i.e. to make sure that the IHOP is
checked more frequently to start marking as soon as its threshold is
crossed (if it has not been). There may be others.

As for the impact, I am not sure, considering that the main problem at
this point is that when getting close to G1ReserverPercent of remaining
space, you are close to getting to the end of available space!

I.e. consider looking at the defaults of G1ReservePercent of 10, this
is not a lot compared to defaults for G1NewSizePercent and
G1MaxNewSizePercent of 5 and 60 respectively.

To use all remaining memory for eden at this point is for obvious
reasons not an excellent idea...

Now you might argue that maybe one should start marking to make sure
that you can use maximum eden at all times. That can be done (set IHOP
manually), but the problem is that this likely causes more frequent
concurrent marking, that also need CPU resources.
Somewhat shorter gc pause intervals typically do not affect total
throughput as much. Additionally, allowing old gen objects to die for
longer typically pays off a lot, i.e. makes the mixed gc phase shorter.

If you feel that above paragraph is a bit too hand-wavy here:
basically, GC heuristics interact in sometimes counter-intuitive ways
with the application. 

Thanks,
  Thomas

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

[prev in list] [next in list] [prev in thread] [next in thread]