Jtreg test resource consumption issues

[Baesken, Matthias]

Hello,
   we sometimes run into resource consumption issues when running the OpenJDK  jtreg tests.
In our central test runs we try to set a reasonable conc level .
However on some smaller test machines, or on test machines with other unpredictable corporate IT tools
running at the same time and causing havoc, a couple of tests run into resource (especially memory) limitations.

On Windows we see in these cases OOM crashes.
Something related is discussed here :

https://bugs.openjdk.org/browse/JDK-8324930
8324930: java/lang/StringBuilder problem with concurrent jtreg runs

On AIX we see messages like "unexpected exit from test" or "Error invoking program" .

E.g.

jdk/java/math/BigInteger/largeMemory/SymmetricRangeTests.java

29   * @requires (sun.arch.data.model == "64" & os.maxMemory >= 10g)
30   * @run main/timeout=180/othervm -Xmx8g -XX:+CompactStrings SymmetricRangeTests

seems to be a candidate (also the other largeMemory tests).

Current approaches to "solve" this are rather poor :
- reduce the concurrency of the jtreg tier - run; this leads to longer execution times of the tier than necessary,
  with only a few tests needing the lower concurrency
- using exclusiveAccess.dirs (see also https://bugs.openjdk.org/browse/JDK-8324930 ) - this is more a workaround and would
  negatively impact other people running the tests with large machines

Would it be possible to have some better support for those resource hungry tests, maybe a special jtreg  test key ?
Currently there is a key "stress" but I am not sure if it is a good fit.
Or maybe have some evaluation of the "requires  os.maxMemory"  settings together with concurrency ?
For example, run with a concurrency of 16 on a 32 G system; and in case a test with os.maxMemory larger some default occurs,
temporary reduce concurrency ?

Maybe there are already some options I did not consider ?

Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jtreg-dev/attachments/20240208/810fbdaf/attachment-0001.htm>