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