RFR: 8265842: G1: Introduce API to run multiple separate tasks in a single gangtask

Thomas Schatzl tschatzl at openjdk.java.net
Fri Apr 23 13:36:23 UTC 2021


On Fri, 23 Apr 2021 11:54:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> [JDK-8214237](https://bugs.openjdk.java.net/browse/JDK-8214237) is going to join different somewhat independent (sub-)tasks of the post evacuation phase into basically two gangtasks to improve performance (reduce startup and shutdown of work gangs).
> 
> To facilitate doing that, introduce an API that manages subtasks of a given gangtask and provide some helpers to do common work.
> 
> This CR is only about adding the API and testing to somewhat simplify the actual move of the post evacuate tasks into parallel tasks. There is no new functionality here, only to split up [JDK-8214237](https://bugs.openjdk.java.net/browse/JDK-8214237) a bit.
> 
> [Here](https://github.com/openjdk/jdk/commit/1d8667143e7d106b96c25c0b876c37f1250be132) is the full change that uses this API to implement JDK-8214237 (which I'll try to split up a bit before) to see how it will be used (in [G1YoungGCPostEvacuateTasks.hpp](https://github.com/openjdk/jdk/commit/1d8667143e7d106b96c25c0b876c37f1250be132#diff-64bc43a24e11978920bb9523cb1507a7275ace22d9eead4c34177339a3258e42) ).
> 
> Testing: new gtest, tier1-5 with mentioned patch for JDK-8214237.
> 
> Thanks,
> Thomas

There is one question I would like to have discussed: to make the code more compact the API uses constructor and destructor for setup/teardown-like methods.

This makes use a bit more clumsy that expected, see the `G1CollectedHeap::post_evacuate_cleanup_1/2` methods:

    void G1CollectedHeap::post_evacuate_cleanup_1(G1ParScanThreadStateSet* per_thread_states,
                                              G1RedirtyCardsQueueSet* rdcqs) {
      Ticks start = Ticks::now();
      {
        G1PostEvacuateCollectionSetCleanupTask1 cl(per_thread_states, rdcqs);
        uint num_threads = MAX2(1u, MIN2(cl.num_busy_workers(), workers()->active_workers()));
        cl.set_max_workers(num_threads);
        workers()->run_task(&cl, num_threads);
       }
       [...]
     }
 
 i.e. since the constructor is used for setup, there is some small code duplication necessary to time execution of such a `G1BatchedGangTask`. @walulyai suggested (similar to other hotspot code) to introduce a `setup` method, but no `teardown`.
 
 There is no reason for me to not to, any concerns or other ideas?

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

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



More information about the hotspot-gc-dev mailing list