<div dir="ltr"><div dir="ltr"><div>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.<br></div><div>The features mainly target the Xms=Xmx case when a program is idling, as most of our desktop and production jobs set Xms=Xmx.</div><div><br></div>The first feature that is responsible for uncommitting memory is similarly to Shenandoah's approach.</div><div dir="ltr">It calls madvise(MADV_DONTNEED) on a subset of free heap pages that are committed by the collector.</div><div dir="ltr">For G1, we added a new type to HeapRegionType::Tag for uncommitted region. The new type is basically a minor type of Free region.</div><div dir="ltr">The feature uses a heuristic to uncommit some regions in HeapRegionManager::_free_list after an old-gen or full collection.</div><div dir="ltr"><div><br></div><div>The second feature controls when to trigger additional old-gen collections in order to trigger the first feature.</div><div>We use a notion called "mutator utilization", which is the percentage of time mutator used since last old-gen collection.</div><div>For G1, it is:</div><div>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</div><div>If mutator utilization exceeds a certain threshold (e.g., >98%), then a concurrent cycle is initiated.</div><div>If mutator utilization is too low (e.g., <40%), it can be used to prevent concurrent collection from happening, reducing GC thrashing.<br></div><div><br></div><div>Comparing to setting Xms!=Xmx, the main benefits of using these two features are:</div><div>- 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;</div><div>- it saves users' configuration effort for figure out different Xms and Xmx values.</div><div><br></div><div>These two features do not reduce memory as much as setting a small Xms, because they do not eagerly compact the heap.</div><div>Basically, they are better suited for workload that prioritizes throughput and performance over memory usage, but still would like memory savings while idling.<br></div><div><br></div><div>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?<br></div><div></div><div dir="ltr"><br></div>The idea of mutator utilization might be interesting by itself. Wessam (CCed) worked on this feature.</div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">(Sorry that I should have brought up these two features in the earlier discussion threads for the JEP)</div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="m_-4568885753717187906m_2279717248426559702m_5196727370550421488gmail-m_3284673381479724309gmail_signature"><div dir="ltr">-Man<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 14, 2018 at 3:18 AM Aleksey Shipilev <<a href="mailto:shade@redhat.com" target="_blank">shade@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/14/2018 12:07 PM, Thomas Schatzl wrote:<br>
>> In terms of the AlwaysPreTouch, I am considering that these are the<br>
>> settings used where people who cares about low latency would use, and<br>
>> these would indicated that the VM should really stop doing things<br>
>> that would cause unintended GC cycle.<br>
> <br>
> I need to think about this, and I am open to suggestions from others.<br>
> This exception as any other seems to make the explanation when it<br>
> happens rather complicated. Disabling it by default may be the better<br>
> solution.<br>
<br>
FWIW, Shenandoah treats -XX:+AlwaysPreTouch as "make sure all heap is committed at all times", and<br>
disables any uncommit, keeping heap always wired up.<br>
<br>
-Aleksey<br>
<br>
</blockquote></div>