RFR: 8370315: [IR-Framework] Allow scenarios to be run in parallel

[Damon Fenacci]

On Thu, 30 Oct 2025 16:27:11 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> Today, the only practical ways to run IR Framework scenarios in parallel seems to be:
> * spawning threads manually in a single test, or
> * letting jtreg treat each scenario as a separate test (the only way to potentially distribute across hosts).
> 
> This makes it a bit cumbersome to use host CPU cores efficiently when running multiple scenarios within the same test.
> 
> ## Change
> This change introduces a method `TestFramework::startParallel` to execute multiple scenarios concurrently. The implementation:
> * launches one task per scenario and runs them in parallel (by default, the maximum concurrency should match the host’s available cores)
> * captures each task’s `System.out` into a dedicated buffer and flushes it when the task completes to avoid interleaved output between scenarios (Note: only call paths within the `compile.lib.ir_framework` package are modified to per-task output streams. `ProcessTools` methods still write directly to `stdout`, so their output may interleave).
> * adds an option `-DForceSequentialScenarios=true` to force all scenarios to be run sequentially.
> 
> ## Testing
> * Tier 1-3+
> * explicit `ir_framework.tests` runs
>   * added IR-Framework test `TestDForceSequentialScenarios.java` to test forcing sequential testing (checkin the output order) and added a parallel run to `TestScenatios.java` (as well as adding `ForceSequentialScenarios` flag to `TestDFlags.java`)
> 
> As reference: a comparison of the execution time between sequential and parallel of all IR-Framework tests using scenarios on our machines (linux x64/aarch64, macosx x64/aarch64, windows x64 with different number of cores, so the results for a single test might not be relevant) gave me an average speedup of 1.9.

The full list of tests using IR-Framework scenarios:

compiler/c2/irTests/gc/ReferenceClearTests.java
compiler/c2/irTests/gc/ReferenceRefersToTests.java
compiler/c2/irTests/igvn/TestCleanMemPhi.java
compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java
compiler/c2/irTests/TestFloat16ScalarOperations.java
compiler/c2/irTests/TestPostParseCallDevirtualization.java
compiler/c2/irTests/TestScheduleSmallMethod.java
compiler/c2/irTests/TestVectorizationMismatchedAccess.java🎲
compiler/gcbarriers/TestG1BarrierGeneration.java
compiler/loopopts/superword/ProdRed_Double.java
compiler/loopopts/superword/ProdRed_Float.java
compiler/loopopts/superword/ProdRed_Int.java
compiler/loopopts/superword/RedTest_int.java
compiler/loopopts/superword/RedTest_long.java
compiler/loopopts/superword/SumRed_Double.java
compiler/loopopts/superword/SumRed_Float.java
compiler/loopopts/superword/SumRed_Int.java
compiler/loopopts/superword/SumRed_Long.java
compiler/loopopts/superword/SumRedAbsNeg_Double.java
compiler/loopopts/superword/SumRedAbsNeg_Float.java
compiler/loopopts/superword/SumRedSqrt_Double.java
compiler/loopopts/superword/TestMemorySegment_8359688.java
compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants1.java
compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants2.java
compiler/loopopts/superword/TestMemorySegmentByteSizeLongLoopLimit.java
compiler/loopopts/superword/TestMemorySegmentField.java
compiler/loopopts/superword/TestMemorySegmentFilterSummands.java
compiler/loopopts/TestArrayFillIntrinsic.java
compiler/vectorization/TestFloatConversionsVector.java


Maybe we could run some of them concurrently (e.g. the ones that show more than a certain speedup to avoid parallelizing short tests that might waste most of the time spawning threads).

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

PR Comment: https://git.openjdk.org/jdk/pull/28065#issuecomment-3473887621