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

[Thomas Schatzl]

Hi all,

  please review the implementation for the not-yet-JEP candidate[0]
registered under JDK-8204089: Timely Reduce Unused Committed Memory[1].

This change introduces a periodic gc that kicks in when the VM has been
idle for some time. This will result in G1 reducing memory footprint,
both native and Java heap memory, if possible in a "timely" fashion.

Idle detection is currently based on GC activity, and optionally based
on system load (default: disabled). Future improvements may add further
conditions as needed.

This periodic gc may be either a continuation of any current concurrent
cycle, optionally a full gc, or just disabled if you want maximum
throughput.

Continuation of current gc cycle means that every time the conditions
for such a periodic gc are met, G1 advances its current state, not
throwing away any recent effort. E.g. assume that the VM gets idle just
after marking completed; now a periodic gc will not throw away these
results, but start the mixed phase, and do mixed collections the next
few times this periodic gc is triggered, compacting the heap in the
process automatically. After that mixed phase it might do another
concurrent mark again, that releases any additional, just emptied
regions.

The optional issuance of a full GC during periodic gc may be more
efficient in returning more memory, at the cost of such a gc.

For more information, I added some example log under the "gc,periodic"
tags see the JEP [1]. In addition to that, such GCs will always have a
cause of "G1 Periodic Collection" to distinguish them from others
easily.

Since this change adds some command line flag there is a CSR too[2],
which gives a shorter summary of the options than in the JEP.

(CC'ing Kirk P. since he was kind of wary of the entire method in early
discussions, but I think the functionality turned out the way he would
like it with default settings).

CR:
https://bugs.openjdk.java.net/browse/JDK-8212657
Webrev:
http://cr.openjdk.java.net/~tschatzl/8212657/webrev/index.html
Testing:
hs-tier1-5, jdk-tier1-3

Thanks,
  Thomas

[0] Usually you would wait for implementation review until it has been
made candidate: however due to timing, basically to spread out the
review workload in the next few weeks for upcoming JEPs, I was allowed
to go ahead with a review request as the JEP has been submitted for a
few weeks, and the change has been done for even longer now. You may
also consider this as pre-review that will be turned review later.
The change will not be pushed before it is targeted of course, i.e.
follow proper further process. 

[1] https://bugs.openjdk.java.net/browse/JDK-8204089

[2] https://bugs.openjdk.java.net/browse/JDK-8212658