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

[Thomas Schatzl]

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 secondmail thread with the second suggestion, which is
probably simpler to do shouldbe 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?
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.jav
a.vm.80.doc/docs/xxidletuningcompactonidle.html
Thanks,  Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180528/a5d44d52/attachment.htm>