RFR: 8297186: G1 triggers unnecessary full GCs when heap utilization is low

Man Cao manc at openjdk.org
Fri Nov 18 00:24:20 UTC 2022


On Thu, 17 Nov 2022 13:14:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that better enforces that after gc there is at least one eden region to allocate into?
> 
> That avoids the problem described in the PR.
> 
> Thanks,
>   Thomas

Thank you for the quick fix!

I haven't fully understood JDK-8253413 yet, so better to have someone more familiar with JDK-8253413 to review this change.

src/hotspot/share/gc/g1/g1Policy.cpp line 191:

> 189: 
> 190: void G1Policy::update_young_length_bounds() {
> 191:   assert_at_safepoint();

This assertion seems to fail in pre-submit build. Might come from G1Policy::init()?

src/hotspot/share/gc/g1/g1Policy.cpp line 283:

> 281:     uint desired_eden_length = MAX3(desired_eden_length_by_pause,
> 282:                                     desired_eden_length_by_mmu,
> 283:                                     MinDesiredEdenLength);

Does this mean `G1Policy::calculate_young_desired_length()` could return 0 instead of a minimum of 1 now? Comment on line 228 may need updating.

I noticed `young_list_desired_length()` is also used in `G1Policy::update_ihop_prediction()`. Could this change mess up with `_ihop_control->update_allocation_info()`?

test/hotspot/jtreg/gc/g1/TestOneEdenRegionAfterGC.java line 48:

> 46:     ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(
> 47:       "-Xbootclasspath/a:.",
> 48:       "-XX:+UnlockDiagnosticVMOptions",

"+UnlockDiagnosticVMOptions" and "import jdk.test.whitebox.WhiteBox" above can be removed.

Not sure about the "@modules java.base/jdk.internal.misc java.management" lines. Could they be removed?

-------------

Changes requested by manc (Committer).

PR: https://git.openjdk.org/jdk/pull/11209


More information about the hotspot-gc-dev mailing list