RFR 8003981: Support Parallel Array Sorting - JEP 103

David Holmes david.holmes at oracle.com
Fri Dec 21 01:49:59 UTC 2012

Hi Chris,

The specdiff is missing the Object variants for some reason.

Otherwise this looks pretty much as I remember it. :)

There is an open question as to whether MIN_ARRAY_SORT_GRAN should be 


On 21/12/2012 3:31 AM, Chris Hegarty wrote:
> This is a review request for the addition of utility methods to
> java.util.Arrays that provide sorting of arrays in parallel, JEP 103 [1].
> Webrev:
> http://cr.openjdk.java.net/~chegar/8003981/ver.00/
> Current sorting implementations provided by the Java Collections
> Framework (Collections.sort and Arrays.sort) all perform the sorting
> operation sequentially in the calling thread. This enhancement will
> offer the same set of sorting operations currently provided by the
> Arrays class, but with a parallel implementation that utilizes the
> Fork/Join framework. These new API’s are still synchronous with regard
> to the calling thread as it will not proceed past the sorting operation
> until the parallel sort is complete.
> The actual sorting API this proposal adds will leverage the
> ForkJoinPool.commonPool (default Fork/Join pool defined as part of JEP
> 155). The sorting algorithm is that used in Doug Lea’s ParallelArray
> implementation.
> This work was originally done over in the lambda/lambda repo by David
> Holmes, and is now being cleaned up and brought into jdk8.
> Open issues/differences from version in lambda:
> 1) Is is necessary for MIN_ARRAY_SORT_GRAN to be in the public API?
> It is an implementation detail (easy to remove).
> 2) The use of FJP.commonPool is an implementation detail, not
> part of the spec. Should not be a problem, just worth pointing
> out, as it differs from what is in lambda/lambda.
> -Chris.
> [1] http://openjdk.java.net/jeps/103

More information about the core-libs-dev mailing list