JEP draft: Timely Reducing Unused Committed Memory [Was. Re: Elastic JVM improvements]
rbruno at gsd.inesc-id.pt
Wed May 30 00:54:21 UTC 2018
added one note inline.
2018-05-28 16:33 GMT+01:00 Thomas Schatzl <thomas.schatzl at oracle.com>:
> so I started to fill out the JEP body template for the first of the
> Could you help completing this as we are waiting for the OCAs? Also a
> mail thread with the second suggestion, which is probably simpler to do
> 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.
> // 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
> // What are the goals of this proposal? Omit this section if you have
> // nothing to say beyond what's already in the summary.
> // 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/~rbruno/publications/rbruno-ismm18.pdf shows an
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%.
> // 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
> Shenandoah and OpenJ9's GenCon collector already provide similar
> // 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.
> // 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
> // 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.
> // 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.
> (We can stuff references like the below in the comments section of the JEP
> I guess)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev