Question regarding JEP 8204089 Timely Reducing Unused Committed Memory

[Thomas Stüfe]

On Fri, Jun 1, 2018 at 2:41 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 06/01/2018 02:10 PM, Zhengyu Gu wrote:
>>> 5)I have not heard of J9 Gencon/Shenandoah providing similar functionality. Can you point me to
>>> further documentation on which feature you model upon?
>>
>> Shenandoah does provide similar functionality under experimental flags:
>>
>> -XX:+ShenandoahUncommit
>> -XX:ShenandoahUncommitDelay
>
> Which are also enabled by default:
>
>      bool ShenandoahUncommit         = true        {experimental} {default}
>     uintx ShenandoahUncommitDelay    = 300000      {experimental} {default}
>      bool ShenandoahUncommitWithIdle = false       {experimental} {default}
>
>
>> It does not need full gc before uncommitting
>
> To be obnoxiously precise, in Shenandoah, the decision to uncommit memory is very loosely tied to
> the GC cycle. It just uncommits the regions that stayed empty for more than ShenandoahUncommitDelay
> milliseconds. This naturally captures the post-GC cleanup when GC freed up enough memory, and the
> lag provides keeps free space committed for the cases where the free memory would be used by the
> active application itself.

Just curious, how expensive is re-committing? I.e. how important is it
to avoid unnecessary uncommits?

>
> As a bonus, Shenandoah uncommits all free memory on explicit GC (e.g. System.gc()), regardless in
> which mode (concurrent or full stw) the cycle was performed. That is the only loose tie to the GC cycle.
>
>> (actually it calls madvise(MADV_DONTNEED) on Linux)
>
> Shenandoah has this capability under ShenandoahUncommitWithIdle, which is not enabled by default. It
> uses the plain old os::uncommit_memory by default.
>
> -Aleksey
>

..Thomas