chore: use JDK11 constructor for ForkJoinPool (support setting maximum spare threads) #32745
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
johanandren
reviewed
Jun 23, 2025
akka-actor/src/main/scala/akka/dispatch/ForkJoinExecutorConfigurator.scala
Outdated
Show resolved
Hide resolved
akka-actor/src/main/scala/akka/dispatch/ForkJoinExecutorConfigurator.scala
Show resolved
Hide resolved
akka-actor/src/main/scala/akka/dispatch/ForkJoinExecutorConfigurator.scala
Outdated
Show resolved
Hide resolved
johanandren
approved these changes
Jun 23, 2025
patriknw
reviewed
Jun 24, 2025
There was a problem hiding this comment.
Looking good.
Mention in docs? https://doc.akka.io/libraries/akka-core/current/typed/dispatchers.html
leviramsey
commented
Jun 24, 2025
| generally mean more context switches by the OS kernel and decreased application throughput with unpredictable latencies. | ||
| Assuming the system remains under load, these spare threads will be kept busy and not become idle; even a relatively | ||
| infrequent use of this mechanism under load may eventually exhaust the ability to add threads, resulting in a crash | ||
| "out of the blue". |
There was a problem hiding this comment.
Really torn on whether to include an "if going down this path, be sure to set maximum-spare-threads" advisory here... I suppose it would be in the spirit of "if skydiving, be sure to have a parachute".
johanandren
approved these changes
Jul 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Scala code (via
BlockContextsoAwait/blocking) and Java code (viaManagedBlocker) can signal a ForkJoinPool that it might be useful to add a worker thread to compensate for the present worker being blocked. For the common pool, the number of additional workers can be bounded by a JVM property (default value is 256);it is unclear whether this property also appliesthis property does not apply to application constructed FJPs like the default dispatcher (or whetherthe effective maximum spare threads for a dispatcher is 2^15 - parallelism). JDK11 adds a constructor which allows setting this maximum (among a few other settings).Regardless of whether the default behavior of the currently-used constructor takes a limit from the property, it seems useful to expose this setting in config. The default chosen is 256 to match the property's default (which is doubtless better than the previous de facto "no limit"
ifthe current behavior is not to consult the property!). In addition to overriding via config, the value of the JDK property for the common pool may also be used (as the default dispatcher is the Akka analogue to the common pool).The priority for setting values for this setting for the default dispatcher (inherited by user-defined dispatchers) is:
akka.actor.default-dispatcher.fork-join-executor.maximum-spare-threadsakka.actor.default-dispatcher.fork-join-executor.maximum-spare-threadsin config (can be overridden by the usual config methods)JVM propertyjava.util.concurrent.ForkJoinPool.common.maximumSparesThe internal dispatcher is hardcoded to have zero spares: there shouldn't be anything that blocks in that dispatcher.