RFR: bug: Timely Reducing Unused Committed Memory

[Thomas Schatzl]

Hi,

On Mon, 2018-10-08 at 22:09 +0300, Ruslan Synytsky wrote:
> Hi Thomas, thank you for the patch. 
> 
> On Mon, 8 Oct 2018 at 17:06, Thomas Schatzl <
> thomas.schatzl at oracle.com> wrote:
> > Hi all,
> > 
> >   here's the promised patch based on latest discussions:
> > 
> > http://cr.openjdk.java.net/~tschatzl/jelastic/pgc-webrev.3/webrev/
> > 
> > It is based on "6490394: G1: Allow heap shrinking / memory
> > unmapping
> > after reclaiming regions during Remark", that is out for review
> > now.
> > 
> > As for the options, they were named as follows:
> > 
> > G1PeriodicGCInterval: Number of milliseconds after a previous GC to
> > wait before triggering a periodic gc. A value of zero disables
> > periodically enforced gc cycles. (Note that I just found out when
> > copy&pasting this description from the g1_globals file that the
> > text I there needs fixing - I will do thatasap :))

(Updated the webrev with all your comments)

> > 
> > G1PeriodicGCInvokesConcurrent: Determines the kind of periodic GC.
> > Set to true to have G1 perform a concurrent GC as periodic GC,
> > otherwise use a STW Full GC.
> 
> Is concurrent enabled by default? If not, then why not?
>  

Concurrent is enabled by default as otherwise this change would
probably accidentally disturb operation too much :)

> > 
> > G1PeriodicGCSystemLoadThreshold: Maximum recent system wide system
> > load at which G1 triggers a periodic GC. A load above this value
> > cancels a given periodic GCs. A value of zero disables this check.
> 
> Maybe a clear mention of loadavg in the description can help to avoid
> potential confusions around system load definition. 

Done.

> 
> > The policy has been implemented so that any reason to not start a
> > periodic collection right now will cancel the current attempt -
> > another attempt will be made after G1PeriodicGCInterval ms. This is
> > different to suppress the periodic gc until the next time the
> > conditions are met.
> > 
> > From a default values POV, periodic gcs will be on by default with
> > an interval of 5mins. This should be fairly non-intrusive for all
> > but exceptional cases.
> > 
> > Please check whether all this still fits your use case :)
> 
> Looks good for me. Thanks again.  

I am currently testing the change a bit more, in particular I found
that the periodic gcs mess up prediction (obviously because they are
occurring during a time when the application is not very active, so the
data they return is not very helpful for normal application behavior).
I fixed that, but there may be some other details lurking that need
fixing. Other than that everything looks good so far (performance,
functional testing).

Meanhwhile I will start updating the JEP again, and kick off the
process (initially mostly internal).

> 
> Btw, we have got an approved session at OracleCode about JVM
> elasticity 
> https://oracle.rainfocus.com/widget/oracle/oow18/catalogcodeone18?search=elastic%2Bjvm
> . I'm planning to bring up topics about general benefits, available
> options with different GCs and JVMs, specifics of running elastic JVM
> in containers, elaboration of possible further improvements. Please
> join the session for a live talk.
> 

Unfortunately I will not attend Code One this year, but I asked Per who
does (he's giving some talk about ZGC if you are interested) to attend
instead. I will certainly follow up on any recording there is :)

Thanks,
  Thomas