The GitHub Actions job "Pull Requests" on pekko.git/fj1.7 has failed.
Run started by GitHub user pjfanning (triggered by pjfanning).

Head commit for run:
051c52dd49e718ea18f902984f768703761a8dd4 / He-Pin(kerr) <[email protected]>
fix: auto-tune ForkJoinPool minimum-runnable on JDK 21+ (#2890)

* fix: auto-tune ForkJoinPool minimum-runnable on JDK 21+

Motivation:
JDK-8300995 / JDK-8321335 changed compensation-thread creation in
ForkJoinPool asyncMode (FIFO) to be much more conservative. Pekko fork-join
dispatchers using the prior default `minimum-runnable = 1` are then prone
to starvation under blocking workloads on JDK 21+, which has shown up as
flaky nightly runs (#2870) and is the root cause behind the workflow
override added in #2889.

Modification:
* Introduce `ForkJoinExecutorConfigurator.resolveMinimumRunnable`, an
  internal helper that computes the effective `minimum-runnable` value
  from the configured value, the dispatcher parallelism, and the running
  JDK major version. A negative configured value (the new default `-1`)
  triggers the JDK-aware policy: on JDK 21+ the value becomes
  `min(8, max(1, parallelism / 2))`; on JDK < 21 it stays at `1`.
  Non-negative values are honoured verbatim, so explicit `0` still
  disables compensation entirely and explicit positive values (including
  `1`) keep their existing meaning.
* Change `pekko.actor.default-dispatcher.fork-join-executor.minimum-runnable`
  in `reference.conf` to the sentinel `-1` and update the doc block to
  describe the new auto-selection rule.
* Add `ForkJoinExecutorConfiguratorSpec` with three groups of assertions:
  (1) pure-function matrix on `resolveMinimumRunnable`; (2) directional
  checks asserting the auto policy strictly raises the value on JDK 21+
  and never exceeds the documented cap of 8; (3) wiring integration that
  builds a `ForkJoinExecutorServiceFactory` from a real dispatcher config
  and verifies the resolved value reaches the factory (guarding against
  regressions of the resolver wiring).

Result:
Production users on JDK 21+ now benefit from the same starvation
mitigation that #2889 bolted onto the nightly CI workflow. Source and
binary compatibility are preserved (constructor defaults stay at `1`,
no signature changes, no MiMa filter required). Users wanting to opt
out can set `minimum-runnable = 1` (or any explicit value) to restore
the previous behaviour.

* fix: address PR review feedback

* License header: replace abbreviated header on the new
  ForkJoinExecutorConfiguratorSpec with the canonical Apache 2.0
  header used by other clean-room test files in the project
  (per pjfanning's review comment).

* Narrow auto-policy scope from JDK 21+ to JDK 25+: nightly evidence
  shows the asyncMode (FIFO) compensation-thread regression
  (JDK-8300995 / JDK-8321335) surfaces most clearly on the JDK 25
  line, while JDK 21 has been running fine on the legacy default of
  1 for years. Keep the default unchanged on JDK 21 to avoid a
  silent behaviour change for users who are not affected.

* Document the new auto-tuning behaviour in both
  docs/src/main/paradox/dispatchers.md (classic) and
  docs/src/main/paradox/typed/dispatchers.md, including the opt-out
  instructions.

* Update reference.conf doc comment, configurator scaladoc, and the
  spec assertions / pending guards to reflect the JDK 25+ scope.

Report URL: https://github.com/apache/pekko/actions/runs/26811359897

With regards,
GitHub Actions via GitBox


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to