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