JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post

[David Holmes]

Hi Janda,

Thanks for the comments.

On 4/10/2011 7:48 PM, Janda Martin wrote:
>
> I hope that this is correct mailing list to comment JEP 103.

It certainly is.

> Proposal: provide static methods for creating sort tasks. This allows developers to have full control over ForkJoinPool.

I'd personally prefer to pass in the FJP to the sort method, rather than 
expose a SortTask type. Though I do cringe at the thought of all the 
additional methods (I wonder if Coin2 would be open to suggesting we add 
default arguments to Java ...)

>    There can be problem with one shared defaultFJPool() in multi-module applications (like Netbeans platform) when two modules requests different FJPool settings.

Although the JEP proposes properties to allow the configuration of the 
default FJPool, the expectation is that:

a) the majority of the time you will use the default configuration 
(desired parallelism level = number of 'processors')

b) any change to the default config is done as a "system" setting, not 
by "local logic". By which I mean that it is not expected that different 
"modules" will attempt to do this configuration. Perhaps we need a way 
to enforce this.

Personally I think there is room to have multiple FJPools in a system, 
but that makes most sense if the pools use disjoint sets of processors - 
which isn't currently supported in Java.

But this is  precisely the kind of feedback we are looking for, so 
thanks again.

David Holmes
------------

> public final class ForkJoinUtils {
>
>    // should this be replaced?
>    public static ForkJoinPool defaultFJPool() { ... }
>
>    public static byte[] parallelSort(byte[] a) { ... }
>    public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex)
>      {...}
>
>    // with this?
>    public static SortTask<byte[]>  createParallelSortTask(byte[] a) {...}
>    public static SortTask<byte[]>  createParallelSortTask(byte[] a, int fromIndex, int toIndex) {...}
>    ...
>
> }
>
> Reaction to Mr. Harned post
>
> I work as a Java SE software developer for several years. I think that Mr. Harned opinion to freeze Java in software history ('30' years ago) is not good idea.
> JSR 166 Fork/Join is great contribution to make Java better (thank you very much Doug Lea). Today CPUs just adds new cores so there have to be better support for parallelism.
>
> j.u.c package isn't only about sorting long arrays (huge overhead). Programs do a lot more.
>
> Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application. They are solid and can be extended/controlled to support specific needs.
>
> I think that Mr. Harned should improve his own libraries to comply with his objections. I looked at his source code, demos and I prefer j.u.c to his work.
>
>    Thank you everybody who works on Java
>
>    Sincerely
>    Martin JANDA
>
> PS sorry for my english