RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
Ivan Walulya
iwalulya at openjdk.org
Thu Apr 20 13:11:50 UTC 2023
On Thu, 20 Apr 2023 13:00:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> 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`.)
I suggest we do that in a follow up CR. For parallel (and I guess for Serial) is that easy, for G1 it requires a bit more code movements.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172564192
More information about the hotspot-gc-dev
mailing list