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