RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent jtreg runs

[Jaikiran Pai]

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Hello Matthias, looking at the crash log you pasted, it's clear that the test itself isn't a culprit here. Specifically, the failure appears to be when a JVM launch is being attempted for the `test/jdk/java/lang/StringBuilder/Insert.java` test (which looking at the code doesn't use too much memory once launched).

What seems to be happening is that the system where this run appears to be launching too many tests concurrently. The exact command used to launch these tests on that setup would be helpful in understanding the configurations. 

The JDK build by default "computes" the `TEST_JOBS` value which controls this concurrency (the number of jtreg concurrent tests to run) and that's done here https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L151 and as noted in testing.md, it is configurable (and has a per system default) https://github.com/openjdk/jdk/blob/master/doc/testing.md#jobs-1. This configuration ultimately translates to the `-concurrency` option of jtreg which is explained in section `3.8 How do I specify whether to run tests concurrently?` and `3.25 My system is unusable while I run tests. How do I fix that?` of the jtreg FAQ https://openjdk.org/jtreg/faq.html.

Based on the available details so far, it appears that you might have to reduce the value for this concurrency option, through the right build/test option.

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1938437285