> See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and > report artificial estimatedSize(), much bigger than the real one. This will > allow AbstractSpliterator and IteratorSpliterator to produce prefix whose > size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), > and this will enable further splitting of the prefix. This change will > drastically improve parallel streaming for affected streams of size <= 1024 > and significantly improve for streams of size 1025..20000. The cost is > higher-grained splitting for huge streams of unknown size. This might add a > minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be > affected, except an extra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used > when parallelizing Stream.iterate source. More testing ideas are welcome.
Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Another testing approach: check splits via collector ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7279/files - new: https://git.openjdk.java.net/jdk/pull/7279/files/2713d5be..726e73e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=01-02 Stats: 14 lines in 1 file changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279
