RFR: 8321816: GenShen: Provide a minimum amount of time for an old collection to run [v4]

Y. Srinivas Ramakrishna ysr at openjdk.org
Thu Dec 21 01:48:14 UTC 2023


On Thu, 21 Dec 2023 00:29:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update stale comment

A few comments for your consideration.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 67:

> 65: }
> 66: 
> 67: void ShenandoahRegulatorThread::regulate_young_and_old_cycles() {

I am wondering if it might not be simpler and clearer to write this method as:


...
while (!should_terminate()) {
  switch (mode) {
     case SCT::none : {
        // no collection is in progress
        // 1. check and start a global collection if needed
        if (should_unload_classes() && start_global_cycle()) {
          log_info...
        } else if (start_old_cycle()) {
           log_info...
        } else if (start_young_cycle()) {
           log_info...
        }
        break;
     }
     case SCT::servicing_old: {
         if (start_young_cycle()) {
           log_info...
         }
         break;
      }
      default: // fall through
   }
   // sleep a tad before next check; sleep duration inversely proportional to allocation rate
   regulator_sleep();   // My worry is that heuristics says wait for old increment and we sleep longer than that? May be that's not an issue?
}
...


The rest of the checks etc. seem already to be done in the `start_...` methods from what I can tell.

I may have missed some subtlety though.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 182:

> 180: }
> 181: 
> 182: bool ShenandoahRegulatorThread::should_unload_classes() {

I'd rename this to:

`should_start_metaspace_gc()`

to avoid confusion with similarly named method in other classes (heuristics) with a different semantics.

Relatedly, do we still need the second check in this method?


bool ShenandoahHeuristics::should_unload_classes() {
  if (!can_unload_classes()) return false;
  if (has_metaspace_oom()) return true;
  return ClassUnloadingWithConcurrentMark;
}


If not, it can be simplified to `return can_unload_classes() && ClassUnloadingWithConcurrentMark;`

I do believe, we should write a line documenting the intended semantics of `should_unload_classes()` in all these places because there ay otherwise be some confusion about what the truth modality "should" really means.

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1791966142
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433342277
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433344949


More information about the shenandoah-dev mailing list