Question regarding JEP 8204089 Timely Reducing Unused Committed Memory

[Aleksey Shipilev]

On 06/01/2018 03:03 PM, Thomas Stüfe wrote:
> On Fri, Jun 1, 2018 at 2:41 PM, Aleksey Shipilev <shade at redhat.com> wrote:
>> 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?

That depends on what the underlying OS memory manager is doing. I don't think it is ignorable,
especially if you are not sure what you exactly you are ignoring :) This is a handy exercise:

$ time java -Xms100g -Xmx100g -XX:+AlwaysPreTouch -XX:+UseTransparentHugePages -XX:+UseSerialGC -version

real	0m15.189s
user	0m0.253s
sys	0m14.924s  // <--- time spent in Linux kernel, clear_page_erms

-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/16f3a7e9/signature.asc>