RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent jtreg runs
Jaikiran Pai
jpai at openjdk.org
Mon Feb 19 14:28:55 UTC 2024
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.
Thank you for those additional details.
> It happens on various machines, two for example
>Windows Server 2022 Standard 16 cores 32G RAM
>Windows Server 2019 Standard 16 cores 32G RAM
>
>On both machines we run :tier1 -avm with -conc:15 (concurrency jtreg flag) .
That then looks like (an extremely high) concurrency of 15 that has been explicitly set when launching those tests. By default, the concurrency gets set to `num_cores/2` (so should have been 8 in your case) https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L152.
I had a quick look at our internal CI, a lot of our Windows systems use 12 core and 24 GB setups (I haven't looked at all of them). The tests on those systems end up using a concurrency of 6 (which is default computed in that RunTests.gmk and matches the `num_cores/2` arithmetic).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952559923
More information about the core-libs-dev
mailing list