Bug ID: JDK-8262185 G1: Prune collection set candidates early

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17
17 b12Fixed

Currently G1 maintains collection set candidates from the marking phase (where it determines those) until the end of the mixed gc phase.

Mixed gc phase ends when the amount of space that can be reclaimed in the java heap with the remaining collection set candidates is smaller than G1HeapWastePercent of the (current) heap capacity.

This means that in some cases a significant amount of memory is used for regions that will never be evacuated. In addition to that, maintaining the remembered sets for these never evacuated regions uses execution time and more memory for the remembered set.

In fact, in some cases, it can happen that in the first few mixed gcs of a mixed gc phase, remembered set memory consumption *increases* even though the remembered sets of recently evacuated old gen regions are freed.

The proposed alternative is to prune the collection set candidates as early as possible, filtering out regions that are never going to be evacuated (or have a very low probability).

In some cases doing this can save half of peak remembered set memory usage.

Changeset: 702ca622 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2021-03-01 11:05:41 +0000 URL: https://git.openjdk.java.net/jdk/commit/702ca622

01-03-2021

Attaching results for a BigRAMTester run showing NMT results (1s interval) of the "GC" subcomponent. Improvement is about 300 MB peak-to-peak out of ~1.6 GB original remembered set memory usage ("floor" for other allocations is around 900-ish MB). So around 20% reduction for this benchmark.

24-02-2021

There are a few nits here that should be considered for evaluation, also comparing against the old heuristic. * There, G1 checks *at the end* of gc whether the remaining collection set candidates are worth collecting (remaining collectible space < G1HeapWastePercent means: stop). Which helps with ensuring at least some forward progress in evacuating the heap because (assuming there are candidates) at least some space will be reclaimed. (I do not know whether this behavior as is is intentional for that reason, but it has been there since initial implementation; then it did not really matter because G1 has been maintaining the old gen remembered sets for all regions all the time anyway). This can be approximated by not removing all of the candidates to have at least one "minimal" mixed collection. * In some cases in the old heuristic G1 would just evacuate all candidate regions (in the extreme in a single gc) if the pause time permitted, reclaiming a bit more space (i.e. that amount < G1HeapWastePercent of the total heap). You would expect (given the default value of 5), there will be more mixed cycles because of that with the new heuristic.

23-02-2021

Duplicate :	JDK-7146242 - G1: alternative heuristic on deciding which old regions not to collect
Relates :	JDK-8017163 - G1: Refactor remembered sets
Relates :	JDK-8331048 - G1: Prune rebuild candidates based on G1HeapWastePercent early
Relates :	JDK-8286467 - G1: Collection set pruning adds one region too many
Relates :	JDK-8180415 - Rebuild remembered sets during the concurrent cycle