> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) > > The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is > both ill-suited for many (if not most) of its applications, and is a > performance bottleneck (as seen especially in Loom and CompletableFuture > usages). After considering many options over the years, the approach taken > here is to connect (lazily, only if used) a form of ScheduledExecutorService > (DelayScheduler) to any ForkJoinPool (including the commonPool), which can > then use more efficient and scalable techniques to request and trigger > delayed actions, periodic actions, and cancellations, as well as coordinate > shutdown and termination mechanics (see the internal documentation in > DelayScheduler.java for algotihmic details). This speeds up some Loom > operations by almost an order of magnitude (and similarly for > CompletableFuture). Further incremental improvements may be possible, but > delay scheduling overhead is now unlikely to be a common performance concern. > > We also introduce method submitWithTimeout to schedule a timeout that cancels > or otherwise completes a submitted task that takes too long. Support for this > very common usage was missing from the ScheduledExecutorService API, and > workarounds that users have tried are wasteful, often leaky, and error-prone. > This cannot be added to the ScheduledExecutorService interface because it > relies on ForkJoinTask methods (such as completeExceptionally) to be > available in user-supplied timeout actions. The need to allow a pluggable > handler reflects experience with the similar CompletableFuture.orTimeout, > which users have found not to be flexible enough, so might be subject of > future improvements. > > A DelayScheduler is optionally (on first use of a scheduling method) > constructed and started as part of a ForkJoinPool, not any other kind of > ExecutorService. It doesn't make sense to do so with the other j.u.c pool > implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already > extends it in incompatible ways (which is why we can't just improve or > replace STPE internals). However, as discussed in internal documentation, the > implementation isolates calls and callbacks in a way that could be extracted > out into (package-private) interfaces if another j.u.c pool type is > introduced. > > Only one of the policy controls in ScheduledThreadPoolExecutor applies to > ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown > controls whether quiescent shutdown should wait for dela...
Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 41 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8319447 - Associate probes with carriers if Virtual (no doc updates yet) - Reduce volatile reads - Address review comments; reactivation tweak - Standardize parameter checking - Address review comments; ensure new internal methods can't clash with subclasses - Address feedback - Misc minor improvements and renamings for clarity - Add optional SubmitWithTimeout action - Merge remote-tracking branch 'refs/remotes/origin/JDK-8319447' into JDK-8319447 - ... and 31 more: https://git.openjdk.org/jdk/compare/4e495e47...f6709108 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23702/files - new: https://git.openjdk.org/jdk/pull/23702/files/0c5d22a3..f6709108 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=05-06 Stats: 44814 lines in 1338 files changed: 20971 ins; 17281 del; 6562 mod Patch: https://git.openjdk.org/jdk/pull/23702.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702 PR: https://git.openjdk.org/jdk/pull/23702
