RFR: 8315692: Parallelize gc/stress/TestStressRSetCoarsening.java test

[Thomas Schatzl]

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.

Similar to PR#15943 I'll do some test runs in our CI to see whether this causes timeouts. There is a risk for smaller machines to be overwhelmed and time out constantly. We may need to revert this change if so.

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

PR Comment: https://git.openjdk.org/jdk/pull/15788#issuecomment-1738606533