RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Paul Sandoz
Hi,

Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>

Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right).

At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.

Paul.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Martin Buchholz-3
You probably want a different summary.

+ * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements


Will this fail if common pool parallelism is odd?

+            int splitsForPHalfC = countSplits(new
ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));


I would drop the word "factor" below:

+     * Default target factor of leaf tasks for parallel decomposition.


Do you ever test with

-Djava.util.concurrent.ForkJoinPool.common.parallelism=0

 * @run junit/othervm/timeout=1000
 *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
 *      --add-opens java.base/java.lang=ALL-UNNAMED
 *      -Djsr166.testImplementationDetails=true
 *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
 *      JSR166TestCase




On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <[hidden email]> wrote:

> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the
> parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-
> stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of
> parallelism and therefore resources utilised (tricky API design problem to
> get right).
>
> At the moment the trick is to run stream executions within a custom pool,
> however the number of fork join tasks created will be in proportion to the
> parallelism of the common pool thus the execution will be over-provisioned.
> This can be especially noticeable on large machines with many cores.
>
> Paul.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Paul Sandoz

> On 8 Nov 2017, at 15:48, Martin Buchholz <[hidden email]> wrote:
>
> You probably want a different summary.
> + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements
>
Doh, indeed.


> Will this fail if common pool parallelism is odd?
> +            int splitsForPHalfC = countSplits(new ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));
>

Yes, the number of splits will be parallelism * 4 rounded up to the nearest power of 2.

I modified the common pool testing and removed the doubling of the parallelism since this might result in OOME when creating the threads.


> I would drop the word "factor" below:
> +     * Default target factor of leaf tasks for parallel decomposition.
>
Ok.


> Do you ever test with
>
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>
>  * @run junit/othervm/timeout=1000
>  *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
>  *      --add-opens java.base/java.lang=ALL-UNNAMED
>  *      -Djsr166.testImplementationDetails=true
>  *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>  *      JSR166TestCase
>

Added. I had to move the test outside of the stream test area, which is set up to run in a more restricted manner.

WebRev updated in place

Thanks,
Paul.

>
>
>
> On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <[hidden email] <mailto:[hidden email]>> wrote:
> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/> <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>>
>
> Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right).
>
> At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.
>
> Paul.
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Martin Buchholz-3
Looks good, but have comments as always.

Fix type: exection

Unrelated typo: the this slice spliterator

I would test core libraries under taskset with an odd number of cpus



On Wed, Nov 8, 2017 at 4:43 PM, Paul Sandoz <[hidden email]> wrote:

>
> On 8 Nov 2017, at 15:48, Martin Buchholz <[hidden email]> wrote:
>
> You probably want a different summary.
>
> + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements
>
>
> Doh, indeed.
>
>
> Will this fail if common pool parallelism is odd?
>
> +            int splitsForPHalfC = countSplits(new ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));
>
>
>
> Yes, the number of splits will be parallelism * 4 rounded up to the
> nearest power of 2.
>
> I modified the common pool testing and removed the doubling of the
> parallelism since this might result in OOME when creating the threads.
>
>
> I would drop the word "factor" below:
>
> +     * Default target factor of leaf tasks for parallel decomposition.
>
>
> Ok.
>
>
> Do you ever test with
>
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>
>  * @run junit/othervm/timeout=1000
>  *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
>  *      --add-opens java.base/java.lang=ALL-UNNAMED
>  *      -Djsr166.testImplementationDetails=true
>  *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>  *      JSR166TestCase
>
>
> Added. I had to move the test outside of the stream test area, which is
> set up to run in a more restricted manner.
>
> WebRev updated in place
>
> Thanks,
> Paul.
>
>
>
>
> On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <[hidden email]>
> wrote:
>
>> Hi,
>>
>> Please review this patch to ensure that a parallel stream obeys the
>> parallelism of a custom fork join pool when it is executed within that pool:
>>
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-st
>> ream-custom-pool/webrev/ <http://cr.openjdk.java.net/~p
>> sandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>>
>> Streams currently do not support capabilities to control the level of
>> parallelism and therefore resources utilised (tricky API design problem to
>> get right).
>>
>> At the moment the trick is to run stream executions within a custom pool,
>> however the number of fork join tasks created will be in proportion to the
>> parallelism of the common pool thus the execution will be over-provisioned.
>> This can be especially noticeable on large machines with many cores.
>>
>> Paul.
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Paul Sandoz

> On 8 Nov 2017, at 18:44, Martin Buchholz <[hidden email]> wrote:
>
> Looks good, but have comments as always.
>
> Fix type: exection
>
> Unrelated typo: the this slice spliterator
>

Fixed.

Thanks,
Paul.

> I would test core libraries under taskset with an odd number of cpus
>



Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Tagir Valeev
In reply to this post by Paul Sandoz
Hello!

Looks good to me, thanks!

With best regards,
Tagir Valeev.

9 нояб. 2017 г. 4:02 AM пользователь "Paul Sandoz" <[hidden email]>
написал:

> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the
> parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-
> stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of
> parallelism and therefore resources utilised (tricky API design problem to
> get right).
>
> At the moment the trick is to run stream executions within a custom pool,
> however the number of fork join tasks created will be in proportion to the
> parallelism of the common pool thus the execution will be over-provisioned.
> This can be especially noticeable on large machines with many cores.
>
> Paul.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Stefan Zobel
In reply to this post by Paul Sandoz
In CustomFJPoolTest#testCustomPools()

>>    assertEquals(splitsForPC, splitsForPHalfC * 2);


I'm sure I'm slow on the uptake, but isn't this bound to
fail for every commonParallelism == 2^n + 1 in the closed
range [2, 127], i.e., for 3, 5, 9, 17, 33, 65?

Regards,
Stefan


2017-11-08 22:01 GMT+01:00 Paul Sandoz <[hidden email]>:

> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right).
>
> At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.
>
> Paul.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Paul Sandoz


> On 11 Nov 2017, at 07:58, Stefan Zobel <[hidden email]> wrote:
>
> In CustomFJPoolTest#testCustomPools()
>
>>>   assertEquals(splitsForPC, splitsForPHalfC * 2);
>
>
> I'm sure I'm slow on the uptake, but isn't this bound to
> fail for every commonParallelism == 2^n + 1 in the closed
> range [2, 127], i.e., for 3, 5, 9, 17, 33, 65?
>

Ooops! yes, thanks for catching that.

I updated the test to do this:

  assertTrue(splitsForPHalfC < splitsForPC);
  assertEquals(splitsForPC / splitsForPHalfC,
               nearestPowerOfTwo(commonParallelism) / nearestPowerOfTwo(commonParallelism / 2));

http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/test/jdk/java/util/stream/CustomFJPoolTest.java.html

Paul.