Why is the ArraySpliterator split from an IteratorSpliterator not IMMUTABLE?
paul.sandoz at oracle.com
Fri Apr 26 06:15:12 PDT 2013
On Apr 26, 2013, at 3:17 AM, John Rose <john.r.rose at oracle.com> wrote:
> Spliterators.java is entertaining reading. There is a trySplit method which has this line of code:
> a = new Object[n];
> Buffering up a split into a flat array is an interesting decision; it feels like marshalling a call for a GPU by creating a flat data set.
We squeeze out some parallelism as long as the cost of processing elements is higher than the cost of creating and copying those elements into arrays. We start with small size arrays and increase in size for each split, which means we can kick off some work quickly and warm up the pool while working on the next split. Also note that the tree-shape produced is right-balanced, so we have to code-defensively in our F/J tasks to avoid SOEs.
See also LinkedList (and some others on j.u.concurrent) for similar implementations that are optimized for the specifics of the collection.
> I'm very curious about the design behind this choice of copying, but I want to ask a simple question first:
> Why is the thing returned from trySplit, that wraps 'a', not marked IMMUTABLE?
> Is this an oversight, or am I missing some subtlety about IMMUTABLE?
Note it is not marked ORDERED either.
We wanted additional characteristics, such as IMMUTABLE, CONCURRENT or ORDERED, to be associated with the source of elements and not with the representation utilized for sub-splits. A source could be mutable (e.g. a LinkedList) and it could also be CONCURRENT (e.g. a key set of a CHM, which is also not ORDERED).
More information about the lambda-dev