RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
Albert Mingkun Yang
ayang at openjdk.org
Thu Apr 20 13:02:53 UTC 2023
On Wed, 19 Apr 2023 11:25:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
>> Hi All,
>>
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of an explicit Full GC call, even if the call is concurrent with an active `GCLocker`. We specify explicit GCs as GCs triggered by the end user in some form (jcmd, System.GC, or WhiteBox testing).
>>
>> The change should also handle the issues reported in JDK-8299276.
>>
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial].
>>
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>
> skip young gcs for parallel too
src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 559:
> 557: !VM_ParallelGCSystemGC::is_cause_full(cause) ||
> 558: op.full_gc_succeeded()) {
> 559: return;
Looking at the caller context, I'd believe all callers expect a GC cycle has just run (by this thread or another) when `collect(cause)` returns. Therefore, the terminating condition should be to check #gc_cycles against the intended gc-type (young or not), sth like:
{
MutexLocker ml(Heap_lock);
if (is_young_gc) {
if (gc_count != total_collections()) {
return;
}
} else {
if (full_gc_count != total_full_collections()) {
return;
}
}
}
(Originally, I was thinking only about full-gc, i.e. systemgc and `_wb_full_gc`, but it also seems reasonable to provide such guarantee, a gc-cycle has run, for `_wb_young_gc`.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172553101
More information about the hotspot-gc-dev
mailing list