-
Bug
-
Resolution: Fixed
-
P3
-
25
-
master
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8364113 | 25 | Alan Bateman | P3 | Resolved | Fixed | master |
The implementation of SubmissionPublisher() was updated as part of JDK-8350493: Improve performance of delayed task handling. This change removed the use of a conditionally selected executor (ASYNC_POOL) and replaced it with a consistent use of ForkJoinPool.asyncCommonPool():
public SubmissionPublisher() {
this(ForkJoinPool.asyncCommonPool(), Flow.defaultBufferSize(), null);
}
Previously, the executor used was defined as:
private static final Executor ASYNC_POOL =
(ForkJoinPool.getCommonPoolParallelism() > 1)
? ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();
This change avoids the overhead of spawning a new thread for each task when ForkJoinPool.commonPool() has zero parallelism. It provides a more consistent and performant behavior for asynchronous task execution.
However, the Javadoc specification of the SubmissionPublisher() constructor still describes behavior in terms of the previously conditional logic based on the parallelism level of the common pool.
Request
The Javadoc specification of the no-arg constructor SubmissionPublisher() still reflects the old behavior that depended on the common pool’s parallelism level. Since the implementation now always uses ForkJoinPool.asyncCommonPool(), the specification must be updated to:
Reflect the consistent use of the asynchronous common pool.
Remove any mention of conditional logic based on ForkJoinPool.getCommonPoolParallelism().
public SubmissionPublisher() {
this(ForkJoinPool.asyncCommonPool(), Flow.defaultBufferSize(), null);
}
Previously, the executor used was defined as:
private static final Executor ASYNC_POOL =
(ForkJoinPool.getCommonPoolParallelism() > 1)
? ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();
This change avoids the overhead of spawning a new thread for each task when ForkJoinPool.commonPool() has zero parallelism. It provides a more consistent and performant behavior for asynchronous task execution.
However, the Javadoc specification of the SubmissionPublisher() constructor still describes behavior in terms of the previously conditional logic based on the parallelism level of the common pool.
Request
The Javadoc specification of the no-arg constructor SubmissionPublisher() still reflects the old behavior that depended on the common pool’s parallelism level. Since the implementation now always uses ForkJoinPool.asyncCommonPool(), the specification must be updated to:
Reflect the consistent use of the asynchronous common pool.
Remove any mention of conditional logic based on ForkJoinPool.getCommonPoolParallelism().
- backported by
-
JDK-8364113 Update SubmissionPublisher() specification to reflect use of ForkJoinPool.asyncCommonPool()
-
- Resolved
-
- csr for
-
JDK-8363552 Update SubmissionPublisher() specification to reflect use of ForkJoinPool.asyncCommonPool()
-
- Closed
-
- relates to
-
JDK-8350493 Improve performance of delayed task handling
-
- Closed
-
- links to
-
Commit(jdk25) openjdk/jdk/3db82624
-
Commit(master) openjdk/jdk/f79bd54b
-
Review(jdk25) openjdk/jdk/26474
-
Review(master) openjdk/jdk/26426
(2 links to)