RFR (M): 8212657: Implementation of JDK-8204089 Promptly Return Unused Committed Memory from G1 [Was: RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory]
sangheon.kim at oracle.com
sangheon.kim at oracle.com
Sun Dec 2 22:34:18 UTC 2018
Hi Thomas,
On 11/12/18 1:39 AM, Thomas Schatzl wrote:
> Hi all,
>
> over the weekend this JEP has been made candidate; there has been a
> name change of the feature to "Promptly Return Unused Committed Memory
> from G1", no other changes.
>
> -------- Forwarded Message --------
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> To: hotspot-gc-dev at openjdk.java.net
> Subject: RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce
> Unused Committed Memory
> Date: Fri, 09 Nov 2018 12:02:17 +0100
>
> Hi all,
>
> please review the implementation for the JEP candidate[0] registered
> under JDK-8204089: Promptly Return Unused Committed Memory from G1[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).
>
> The initial implementation and ideas have been contributed by Rodrigo
> Bruno from University of Lisbon and Ruslan Synytsky from JElastic with
> lots of additional input from the community.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8212657
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8212657/webrev/index.html
Looks good.
I have just minor nits:
---------------
src/hotspot/share/gc/shared/gcCause.cpp
src/hotspot/share/gc/shared/gcCause.hpp
src/hotspot/share/gc/shared/vmGCOperations.cpp
- Copyright update
---------------
test/hotspot/jtreg/gc/g1/ihop/TestIHOPErgo.java
- runTest(64, 50, true);
+ runTest(64, 100, true);
- Why we need this change? This feature is basically disabled.
---------------
73 System.out.println("Skipped. Initial heap size is too
close to max heap size.");
- The log message slightly makes me confused. The test is skipped
because we don't have enough free/available memory to run the test
without triggering GC. 'Initial heap size' was looking as
'InitialHeapSize' at first. :)
Thanks,
Sangheon
> Testing:
> hs-tier1-5, jdk-tier1-3
>
> Thanks,
> Thomas
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8204089
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8212658
>
>
>
>
>
More information about the hotspot-gc-dev
mailing list