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