Question regarding JEP 8204089 Timely Reducing Unused Committed Memory

[Aleksey Shipilev]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180601/1cce2cbd/signature.asc>