JEP draft: Timely Reducing Unused Committed Memory [Was. Re: Elastic JVM improvements]

Wed May 30 19:43:54 UTC 2018

Hi Rodrigo,

  fyi, I filed https://bugs.openjdk.java.net/browse/JDK-8204089 for
this feature and copy&pasted the text we have there.

Thanks,
  Thomas

On Wed, 2018-05-30 at 01:54 +0100, Rodrigo Bruno wrote:
> Hi,
> 
> added one note inline.
> 
> 2018-05-28 16:33 GMT+01:00 Thomas Schatzl <thomas.schatzl at oracle.com>
> :
> > Hi,
> > 
> >   so I started to fill out the JEP body template for the first of
> > the improvements.
> > Could you help completing this as we are waiting for the OCAs? Also
> > a second
> > mail thread with the second suggestion, which is probably simpler
> > to do should
> > be started.
> > 
> > Timely Reducing Unused Committed Memory
> > 
> > (from http://openjdk.java.net/jeps/2)
> > 
> > //
> > // JDK Enhancement Proposal ("JEP") body template, v2.0
> > //
> > // ==> Delete all lines starting with "//"
> > //     before entering a proposal into JBS
> > //
> > // Instances of this template are meant to be evolving
> > documents.  When
> > // you initially draft a JEP you don't need to fill out every
> > section of
> > // the template, and in fact at that point you probably won't be
> > able to
> > // do so.  As you get feedback and build consensus around your
> > proposal
> > // you'll revise the JEP accordingly.  If your JEP is accepted and
> > targeted
> > // then you'll continue to revise it as the work progresses so
> > that, once
> > // it's complete, the JEP can serve as an authoritative record of
> > what
> > // was actually done.
> > //
> > // The body of a JEP uses the Markdown markup language
> > // (http://daringfireball.net/projects/markdown/basics).
> > //
> > // All sections are optional except those marked REQUIRED.  Keep
> > sections
> > // in the order shown below.  If an optional section is not needed
> > them
> > // simply omit it rather than write something like "None".  Do not
> > add
> > 
> > (I violated this, but since this text not final anyway it does not
> > matter)
> > 
> > // sections beyond those defined in the template.
> > //
> > // Use lines of dashes ("----") under section titles, not equals
> > signs
> > // ("====").  If you need subsections then use the "###" prefix
> > before
> > // subsection headings and "####" before sub-subsection
> > headings.  Do not
> > // use HTML markup (<h2>, etc.) for section headings.  In general,
> > avoid
> > // HTML markup unless it's absolutely necessary.
> > 
> > Summary
> > -------
> > 
> > // REQUIRED -- Provide a short summary of the proposal, at most one
> > or two
> > // sentences.  This summary will be rolled up into feature lists,
> > JSRs, and
> > // other documents, so please take the time to make it short and
> > sweet.
> > 
> > Make the G1 garbage collector automatically release unused memory
> > when idle.
> > 
> > Goals
> > -----
> > 
> > // What are the goals of this proposal?  Omit this section if you
> > have
> > // nothing to say beyond what's already in the summary.
> > 
> > 
> > Non-Goals
> > ---------
> > 
> > // Describe any goals you wish to identify specifically as being
> > out of
> > // scope for this proposal.
> > 
> > 
> > 
> > Success Metrics
> > ---------------
> > 
> > // If the success of this work can be gauged by specific numerical
> > // metrics and associated goals then describe them here.
> > 
> > From paper?
> > 
> > 
> 
> Section 5.5 of the paper available at http://www.gsd.inesc-id.pt/~rbr
> uno/publications/rbruno-ismm18.pdf shows an experiment
> based on real-world utilization where a tomcat server is used to
> serve http requests during the day (and it is mostly idle during the
> night). The experiment shows that this solution can reduce the
> commited memory by 85%.
>  
> > Motivation
> > ----------
> > 
> > // Why should this work be done?  What are its benefits?  Who's
> > asking
> > // for it?  How does it compare to the competition, if any?
> > 
> > Currently the JVM garbage collectors may not give back committed
> > Java heap memory to the operating system in a timely manner. Its
> > garbage collectors only shrink the Java heap at the end of a full
> > collection. G1 in particular tries to completely avoid them, which
> > means that it may never return Java heap memory unless forced
> > externally.
> > 
> > This is particularly disadvantageous in a container environment
> > where resources are paid by use. Even during phases where the VM
> > only uses a fraction of its assigned memory resources, customers
> > pay for all resources all the time, and cloud providers can not
> > fully utilize their hardware.
> > 
> > If the VM were able to detect phases of heap underutilization
> > ("idle" phases), and in turn automatically reduce its heap usage,
> > both would benefit.
> > 
> > Shenandoah and OpenJ9's GenCon collector already provide similar
> > functionality.
> > 
> > Description
> > -----------
> > 
> > // REQUIRED -- Describe the enhancement in detail: Both what it is
> > and,
> > // to the extent understood, how you intend to implement
> > it.  Summarize,
> > // at a high level, all of the interfaces you expect to modify or
> > extend,
> > // including Java APIs, command-line switches, library/JVM
> > interfaces,
> > // and file formats.  Explain how failures in applications using
> > this
> > // enhancement will be diagnosed, both during development and in
> > // production.  Describe any open design issues.
> > //
> > // This section will evolve over time as the work progresses,
> > ultimately
> > // becoming the authoritative high-level description of the end
> > result.
> > // Include hyperlinks to additional documents as required.
> > 
> > To accomplish this goal, the HotSpot JVM periodically triggers a
> > full collection to maximally compact the Java heap and uncommit
> > unused memory if below conditions are met.
> > 
> > Two full collections should not be separated by more than
> > GCFrequency seconds. The GCFrequency value is ignored and
> > therefore, i.e., no full collection is triggered, if:
> > 
> >  - GCFrequency is zero;
> >  - the average load on the host system is above MaxLoadGC. The
> > average load is defined as per the os::load_avg() call. This check
> > is ignored if MaxLoadGC is zero;
> >  - the committed memory is above MinCommitted bytes. This check is
> > ignored if MinCommitted is zero;
> >  - the difference between the current heap capacity and the current
> > heap usage is below MaxOverCommitted bytes. This check is ignored
> > if MaxOverCommitted is zero;
> > 
> > All these command line options are dynamically user-defined
> > variables. They can be modified at runtime.
> > 
> > Alternatives
> > ------------
> > 
> > // Did you consider any alternative approaches or technologies?  If
> > so
> > // then please describe them here and explain why they were not
> > chosen.
> > 
> > Similar functionality could be achieved via tools like jcmd or
> > MBean, but has hidden costs: assuming that the check is performed
> > using a cron-based task, in case of hundreds or thousands of
> > containers on a node this may mean that the heap compaction action
> > is performed at the same time by many of these containers, which
> > gives very large CPU spikes on the host.
> > 
> > Another alternative option could be a Java agent which is
> > automatically attached to each java process. Then the check time is
> > distributed naturally as containers start at different time, plus
> > it's less expensive on CPU because you do not launch any new
> > process. However this method adds complexity to users outside of
> > cloud hosting companies, which may prevent adoption.
> > 
> > Testing
> > -------
> > 
> > // What kinds of test development and execution will be required in
> > order
> > // to validate this enhancement, beyond the usual mandatory unit
> > tests?
> > // Be sure to list any special platform or hardware requirements.
> > 
> > No special testing environment needed.
> > 
> > Risks and Assumptions
> > ---------------------
> > 
> > // Describe any risks or assumptions that must be considered along
> > with
> > // this proposal.  Could any plausible events derail this work, or
> > even
> > // render it unnecessary?  If you have mitigation plans for the
> > known
> > // risks then please describe them.
> > 
> > 
> > 
> > Dependencies
> > -----------
> > 
> > // Describe all dependencies that this JEP has on other JEPs, JBS
> > issues,
> > // components, products, or anything else.  Dependencies upon JEPs
> > or JBS
> > // issues should also be recorded as links in the JEP issue itself.
> > //
> > // Describe any JEPs that depend upon this JEP, and likewise make
> > sure
> > // they are linked to this issue in JBS.
> > 
> > None.
> > 
> > (We can stuff references like the below in the comments section of
> > the JEP I guess)
> > 
> > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm
> > .java.vm.80.doc/docs/xxidletuningcompactonidle.html
> > 
> > Thanks,
> > Thomas
> > 