RFR: 8277893: Arraycopy stress tests [v3]

[Aleksey Shipilev]

On Mon, 6 Dec 2021 10:17:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I would like to fork the new tests off the JDK-8150730. These tests were instrumental in capturing many bugs in my arraycopy work, and I think they are good on their own merit, because they provide a test for the current baseline and on-going minor improvements in arraycopy on all platforms, not only x86_64, and they might be cleanly backportable.
>> 
>> A brief tour of these tests:
>> 
>> - Tests all data types;
>> - Tests small arrays exhaustively, which captures conjoint/disjoint cases, errors near the edges, etc;
>> - Tests large arrays with fuzzing around powers of two and powers of ten, both conjoint and disjoint cases;
>> - Tests all available compilation modes for arraycopy stubs; for example, running on AVX-512 enabled machine runs all versions down to `-XX:UseAVX=0 -XX:UseSSE=0` cases;
>> - Tests with/without compressed oops mode -- theoretically only needed for `Object` copies, but Hotspot cobbles together int+coops and long+no-coops loops, so I decided to alternate coops mode for all data types;
>> 
>> My previous version used individual `@run` clauses for all configurations, but I think the Java driver is cleaner and easier to maintain.
>> 
>> Test times:
>> 
>> 
>> # x86_64 (TR 3970X)
>> real	4m6.192s
>> user	52m50.523s
>> sys	0m13.755s
>> 
>> # x86_64 (TR 3970X) -XX:+UseZGC
>> real	6m2.573s
>> user	72m43.541s
>> sys	0m25.697s
>> 
>> # x86_32 (TR 3970X)
>> real	6m56.405s
>> user	92m56.377s
>> sys	0m6.677s
>> 
>> # x86_64 (i5-11500)
>> real	29m19.024s
>> user	103m52.925s
>> sys	1m7.175s
>> 
>> # AArch64 (ThunderX2)
>> real	2m59.623s
>> user	26m14.624s
>> sys	0m9.771s
>> 
>> 
>> Since these tests are quite long, especially on small machines, I hooked them up to `hotspot:tier3`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `compiler/stress/arraycopy`
>>  - [x] Linux x86_32 fastdebug `compiler/stress/arraycopy`
>>  - [x] Linux AArch64 fastdebug `compiler/stress/arraycopy`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Package declarations
>  - Add safety check for small systems
>  - Renames
>  - Single driver for all the tests
>  - Safer timeout settings
>  - Post-merge TEST.groups cleanup
>  - Merge branch 'master' into JDK-8277893-arraycopy-tests
>  - Merge branch 'master' into JDK-8277893-arraycopy-tests
>  - Separate test group and hooks into hotspot_slow_compiler
>  - Trim down MAX_SIZE and explain the choice
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fffcc8b...118a3eb2

Yes, definitely GC arraycopy barriers in object array copy cases. Shenandoah cuts the overhead in half by emitting the runtime check on GC state, so it can skip calling to runtime in most cases. ZGC calls to runtime for all object copies. This adds up quite a bit for small object arrays.

I looked whether to trim down the array sizes we feed into these tests, but that does not look compelling to me, as these tests were useful with current settings in arraycopy improvements work. The GC specific overheads also make object array tests take a disproportionate amount of time, wrecking parallelism that might have helped to subsume these penalties.

So, new work:
 a) Sets up larger timeouts to cater for slow machines;
 b) Rewrites the per-type tests to use a single driver, so it can balance over single-type jobs;
 c) Defaults the stress parallelism to `N_CPU / 4`

New test times are updated in PR body. @vnkozlov, would you like to try this in Oracle infra again?

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

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