RFR: 8268163: Change the order of fallback full GCs in G1

Stefan Johansson sjohanss at openjdk.java.net
Wed Jun 9 08:48:14 UTC 2021

On Wed, 9 Jun 2021 08:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1VMOperations.cpp line 103:
>>> 101:     // the GCLocker check in the prologue.)
>>> 102:     _transient_failure = true;
>>> 103:   } else if (g1h->should_upgrade_to_full_gc(_gc_cause)) {
>> I think there is a pre-existing bug here: `should_upgrade_to_full_gc` always returns `false` here because the called `should_do_concurrent_full_gc()` used there (and returning true) is always true for `VM_G1TryInitiateConcMark`.
>> Afaict this has been introduced in (https://bugs.openjdk.java.net/browse/JDK-8232588) where `VM_G1CollectForAllocation` has been split into `VM_G1TryInitiateConcMark` and `VM_G1CollectForAllocation`, and `should_upgrade_to_full_gc()` not updated.
>> Tote that JDK-8232588 suggests to *not* upgrade for a `System.gc` call with `-XX:+ExplicitGCInvokesConcurrent`, but strangely adds the code to do so. Later, JDK-8232588, due to some refactoring error, disables the upgrade again.
>> I'll file a bug to investigate this (mess).
> At the time of JDK-8232588 the `should_do_concurrent_full_gc()` check was preceded by a check of `policy()->force_upgrade_to_full()` that could make the full GC happen.  That seems to have disappeared.

Yes, that was removed when we removed the support for old-gen och alternative memory device. I think having a bug/enhancement to investigate how to improve this is good.


PR: https://git.openjdk.java.net/jdk/pull/4342

More information about the hotspot-gc-dev mailing list