RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory

[Man Cao]

Google has two similar features to reduce idling process's memory
footprint. Both features were initially implemented in CMS and have been
reimplemented for G1.
The features mainly target the Xms=Xmx case when a program is idling, as
most of our desktop and production jobs set Xms=Xmx.

The first feature that is responsible for uncommitting memory is similarly
to Shenandoah's approach.
It calls madvise(MADV_DONTNEED) on a subset of free heap pages that are
committed by the collector.
For G1, we added a new type to HeapRegionType::Tag for uncommitted region.
The new type is basically a minor type of Free region.
The feature uses a heuristic to uncommit some regions
in HeapRegionManager::_free_list after an old-gen or full collection.

The second feature controls when to trigger additional old-gen collections
in order to trigger the first feature.
We use a notion called "mutator utilization", which is the percentage of
time mutator used since last old-gen collection.
For G1, it is:
mutator_utilization = 1 - (last_concurrent_mark_duration +
total_mixed_gc_duration_since_last_concurrent_mark +
total_full_gc_duration_since_last_concurrent_mark) /
time_since_start_of_last_concurrent_mark
If mutator utilization exceeds a certain threshold (e.g., >98%), then a
concurrent cycle is initiated.
If mutator utilization is too low (e.g., <40%), it can be used to prevent
concurrent collection from happening, reducing GC thrashing.

Comparing to setting Xms!=Xmx, the main benefits of using these two
features are:
- it avoids the cost of shrinking/expanding the heap, while saving memory
when process idles. The cost of re-committing pages previously marked as
MADV_DONTNEED is lower than triggering more collections to resize the heap;
- it saves users' configuration effort for figure out different Xms and Xmx
values.

These two features do not reduce memory as much as setting a small Xms,
because they do not eagerly compact the heap.
Basically, they are better suited for workload that prioritizes throughput
and performance over memory usage, but still would like memory savings
while idling.

It would be nice if we could merge these ideas/features into this JEP. Or
maybe they can be in another JEP that targets the Xms=Xmx case?

The idea of mutator utilization might be interesting by itself. Wessam
(CCed) worked on this feature.
It is orthogonal to G1UseAdaptiveIHOP to control when to start a concurrent
cycle. We also found it is useful to reduce GC cost in production workload
by setting a higher minimum bound to prevent concurrent cycles.

(Sorry that I should have brought up these two features in the earlier
discussion threads for the JEP)

-Man


On Wed, Nov 14, 2018 at 3:18 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 11/14/2018 12:07 PM, Thomas Schatzl wrote:
> >> In terms of the AlwaysPreTouch, I am considering that these are the
> >> settings used where people who cares about low latency would use, and
> >> these would indicated that the VM should really stop doing things
> >> that would cause unintended GC cycle.
> >
> > I need to think about this, and I am open to suggestions from others.
> > This exception as any other seems to make the explanation when it
> > happens rather complicated. Disabling it by default may be the better
> > solution.
>
> FWIW, Shenandoah treats -XX:+AlwaysPreTouch as "make sure all heap is
> committed at all times", and
> disables any uncommit, keeping heap always wired up.
>
> -Aleksey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181114/746e1cfa/attachment.htm>