JDK-8227018 : CompletableFuture should not call Runtime.availableProcessors on fast path
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 8u191
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-01
  • Updated: 2019-11-29
  • Resolved: 2019-07-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8u241Fixed openjdk8u232Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
In 8u, CompletableFuture calls Runtime.availableProcessors during spin in waitingGet:

    private Object waitingGet(boolean interruptible) {
        while ((r = result) == null) {
            if (spins < 0)
                spins = (Runtime.getRuntime().availableProcessors() > 1) ?
                    1 << 8 : 0; // Use brief spin-wait on multiprocessors

Unfortunately, that falls victim to JDK-8227006, which makes it too costly. This is fixed in 9 with JDK-8134851, but that patch is too large and intrusive to backport to 8u. Therefore, we should consider backporting the small part of that patch that deals with availableProcessors handling.
URL: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/31d3c2937dcb User: andrew Date: 2019-07-30 13:53:14 +0000

Fix Request (8u) This fixes a performance regression due to added container support in 8u. It is implicitly fixed in 9+, but requires a separate change in 8u. Passes "tier1"-like tests. 8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009746.html

This would be OK. The method was updated in JDK9 not to use this spin anyway, so the only impact is on 8.

Doug (Lea), do you agree this patch is sensible?

Yup. I was thinking this: http://cr.openjdk.java.net/~shade/8227018/webrev.01/

As we only care about >1 processors we can cache this value in a field. The only problem case would be a >1 to 1 transition which is an unlikely change. If it did occur it would only result in a small performance hit anyway.