Support saturating the ForkJoinPool via a property

[mpkorstanje]

Overview

The JUnit Platform now supports saturating the ForkJoinPool via a property.
Enabling this property will limit the number of concurrently executing tests
will to the configured parallelism even when some are blocked.

For JUnit Jupiter this can be enabled by through the
junit.jupiter.execution.parallel.config.dynamic.saturate and
junit.jupiter.execution.parallel.config.fixed.saturate configuration
properties.

Fixes: #2545
Fixes: #1858
Fixes: #3026

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes
• All continuous integration builds pass

[mpkorstanje]

The windows build fails with java.lang.StackOverflowError (no error message) but I've got no way to reproduce this.

[marcphilipp]

Fixes: #2545
Fixes: #1858
Fixes: #3026

@mpkorstanje Could you please briefly explain why all three issues would be fixed by merging this PR?

[mpkorstanje]

The solution to #1858 and #2545 comes from ensuring the number of running tests does not exceed the desired parallelism. This can be achieved by implementing a strategy that returns a ParallelExecutionConfiguration with saturate = () -> true and parallelism = maxPoolSize = <desired parallelism>.

Unfortunately I overlooked that both the fixed and dynamic strategy adds an additional 256 threads to the maximum pool size, so merely allowing the pool to be saturated doesn't solve the problem.

junit5/junit-platform-engine/src/main/java/org/junit/platform/engine/support/hierarchical/DefaultParallelExecutionConfigurationStrategy.java

Lines 45 to 46 in 34ccae7

	return new DefaultParallelExecutionConfiguration(parallelism, parallelism, 256 + parallelism, parallelism,
	KEEP_ALIVE_SECONDS);

Adding a *.max-pool-size property would resolve that.

[mpkorstanje]

On second thought, only fixed.saturate and fixed.max-pool-size make sense. I can't think of any benefits the dynamic strategy would get.

[mpkorstanje]

And on third thought, with the fixed strategy is there a reason not to allow the fork join pool to be saturated. Tests rejected by the pool would fail when the pool could not be saturated, but what value would that have?

[mpkorstanje]

I'll come back to this when I've got a coherent proposal.