RFR: 8315692: Parallelize gc/stress/TestStressRSetCoarsening.java test
Aleksey Shipilev
shade at openjdk.org
Wed Sep 27 08:56:14 UTC 2023
On Mon, 18 Sep 2023 13:24:59 GMT, Soumadipta Roy <duke at openjdk.org> wrote:
> Looking at tier4 tests, gc/stress tests take lots of time per test. For example TestStressRSetCoarsening takes about 33 minutes to runin fastdebug mode in macos arm cpu. This limits effective parallelism of tier4 testing on large machines. We can parallelize its `@run` configs to improve effective parallelism for tier4. Below are some of the observation from before any change, partial parallelization and full parallelization:
>
> * before_release : **585.70s user 23.80s system 106% cpu 9:32.16 total**
> * before_fastdebug : **2033.77s user 30.04s system 105% cpu 32:43.10 total**
> * fully-parallelized_fastdebug : **2246.94s user 36.97s system 135% cpu 28:07.24 total**
> * fully-parallelized_release : **463.52s user 31.54s system 234% cpu 3:31.19 total**
> * partially-parallelized_release : **461.15s user 20.88s system 257% cpu 3:06.91 total**
>
> Even though partial parallelization shows better results it has anomaly 33%-50% of the time where the run results are same as before_release. I have runn each of the above combinations multiple times to establish a consistency and fully parallel gives us the most benefit in terms of total time without deviating too much on user and system times.
This looks okay to me, with minor nits.
@tschatzl might want to take a look too.
test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java line 33:
> 31: * @key stress
> 32: * @bug 8146984 8147087
> 33: * @summary Stress G1 Remembered Set by creating a lot of cross region links
Please don't move the `@summary`, if you can avoid it?
-------------
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/15788#pullrequestreview-1640368182
PR Review Comment: https://git.openjdk.org/jdk/pull/15788#discussion_r1334643062
More information about the hotspot-gc-dev
mailing list