RFR 8080623 CPU overhead in FJ due to spinning in awaitWork

[David Holmes]

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.
>
>
>