RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests

[David Holmes]

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

I suspect it was simply the fact that these were stress tests that resulted in them being executed in isolation. Otherwise if the concurrency level is just wrong I would expect these to cause intermittent failures when run in parallel. I will ask Misha to respond here (can't locate his OpenJDK tag :( ).

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

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