On 20/05/2015 3:55 AM, Paul Sandoz wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8080623
diff -r ea3ca5cfc3c6
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
--- a/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
Tue May 19 20:04:29 2015 +0300
+++ b/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
Tue May 19 19:54:00 2015 +0200
@@ -1328,13 +1328,9 @@
/**
* Number of times to spin-wait before blocking. The spins (in
* awaitRunStateLock and awaitWork) currently use randomized
- * spins. If/when MWAIT-like intrinsics becomes available, they
- * may allow quieter spinning. The value of SPINS must be a power
- * of two, at least 4. The current value causes spinning for a
- * small fraction of typical context-switch times, well worthwhile
- * given the typical likelihoods that blocking is not necessary.
+ * spins. Currently set to zero to reduce CPU usage.
I'd keep the commentary even if disabling spinning at this time.
David
-----
*/
- private static final int SPINS = 1 << 11;
+ private static final int SPINS = 0;
/**
* Increment for seed generators. See class ThreadLocal for
This is a quick fix from Doug to reduce the CPU usage in F/J computations that
was introduced with the fix for JDK-805624 to reduce thread construction. Many
thanks to Staffan Friberg for doing the performance work and analysis.
The F/J pool makes a worker thread spin for a bit while waiting for more work
to become available rather than immediately blocking. This results in higher
CPU usage and can cause performance regressions since there is less CPU
resources available to other threads or applications.
The interim fix is to turn off spinning. This has the effect of making
questionable cases worse (e.g. parallel streams with an inappropriate small
number elements).
It will be back ported to 8u60 and it is planned that a better solution will be
introduced in 9 (and time permitting it may be possible to backport that).
Paul.
