RFR (S/M): 8136678: Implement adaptive sizing algorithm for IHOP

[Thomas Schatzl]

Hi Kirk,

On Thu, 2015-11-19 at 12:25 +0100, kirk.pepperdine at gmail.com wrote:
> Hi Thomas,
>
> Sorry to jump in what maybe a bit late but I wasn’t following this
> thread. Also, I’ll confess to have not looked at the code just yet so
> this maybe a concern that has already been addressed. The point in
> question is
>
> > > might be better as
> > > 
> > > 103 // based on predictions of current allocation rate and time
> > > periods between
>
> What I have seen with the current implementations of adaptive sizing
> is that they are almost completely influenced by current allocation
> rates which can lead to an interesting pathological condition. I’ve
> attached a screenshots which I hope makes it to you.

... on predictions of...

(which take the past into account)

And this change is NOT about adaptive _heap_ sizing.

The change is about adaptively determining the IHOP value. We do not
want you think about this in the future.
> 
> What you can see in the screen shot is that allocation rates drop as
> soon as the system changes from a normal GC cycle to only running Full
> GCs. The subsequent drop in allocation rates results in adaptive
> sizing deciding to reduce the size of tenured/heap (in an application
> that is already obviously struggling for memory). Note, this is a
> temporary condition, there is no memory leak, so I wouldn’t expect an
> OOME to be thrown here. It’s also not a condition in which I’d expect
> adaptive sizing to shrink heap. Recent full gc frequency would be a
> signal for PS not to shrink but I’m not sure what would be a signal
> for the G1 to not take memory away under these conditions. Yes, the
> proper answer is to use a bigger heap but we sometimes accidentally
> get into these conditions and it’s nice if the system can work it’s
> way though them.
> 
G1 mostly bases its heap sizing decisions on the mutator/gc time ratio.

Iirc the (known) bug is that G1 does not take full gcs into its gc time
ratio calculations into account (because it screws it up in a major way
- at least that is my suspicion for this behavior). Not sure if there is
already a CR.

Thanks for reporting this problem.

Thanks,
  Thomas