RFR: 8277757: Parallelize humongous reclaim

Stefan Johansson sjohanss at openjdk.java.net
Tue Nov 30 13:05:11 UTC 2021

On Tue, 30 Nov 2021 12:40:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to use parallel threads for humongous reclaim.
>> **Summary**
>> The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 
>> **Testing**
>> - [x] Mach5 tier 1-3
>> - [x] Local testing verifying JFR tests are unaffected
>> - [x] Performance testing checking for regressions
> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 290:
>> 288:   }
>> 289: 
>> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
> Would it be possible to pack `_humongous_reclaim_candidates` into `should_execute()`? Without candidates, there should be no need to even try this phase. There needs to be some adjustment with the log messages though.
> Then `worker_cost` also does not need the `MAX2` then.

I was thinking the same, but it looks like we want to execute this phase for logging purposes as well: 

bool G1CollectedHeap::should_do_eager_reclaim() const {
  // As eager reclaim logging also gives information about humongous objects in
  // the heap in general, always do the eager reclaim pass even without known
  // candidates.
  return (G1EagerReclaimHumongousObjects &&
          (has_humongous_reclaim_candidates() || do_humongous_object_logging()));

So if `gc+humongous=debug` we will also execute this task.


PR: https://git.openjdk.java.net/jdk/pull/6612

More information about the hotspot-gc-dev mailing list