RFR: bug: Timely Reducing Unused Committed Memory

Ruslan Synytsky synytskyy at jelastic.com
Sat Oct 13 12:21:47 UTC 2018


On Thu, 11 Oct 2018 at 17:55, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> 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 :)

Hi Thomas, yes, I’m definitely interested. How can I contact Per directly?
As I would like to mention ZGC specifics related to the elasticity at my
session.
Thanks

>
>
> Thanks,
>   Thomas
>
>
>

-- 
Ruslan
CEO @ Jelastic <https://jelastic.com/>
-- 
Ruslan
CEO @ Jelastic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181013/ae49615a/attachment.htm>


More information about the hotspot-gc-dev mailing list