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

[Damon Fenacci]

On Mon, 3 Nov 2025 06:47:45 GMT, Christian Hagedorn <chagedorn 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.
>
> test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java line 762:
> 
>> 760:                 outcome = new Outcome(scenario, null, null);
>> 761:             } catch (TestFormatException e) {
>> 762:                 outcome = new Outcome(scenario, e, null);
> 
> Why do you collect the format exceptions here and only throw them later? Is a fail-fast not possible?

Actually it is (maybe a bit more tricky but possible). Changing this...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28065#discussion_r2486955518