j.u.s.Stream and Fiber

[Thomas May]

What about a new ExecutorService which simply creates a fiber per task?  FiberService or whatever.

That should be relatively easy to create and would plug right into most of these APIs without too much effort.  The stream API could do the same thing it currently does with the fork join pool,  That is, ask the current thread (or fiber?) if it is a member of the FiberService.  If so, use it.

If fiber service is fast enough, maybe we simply swap out the current fork join pool for the fiber service?  If not, it is easy enough to plug it in where it is needed.

> I agree that this is a good time to bring this up, but I also want to set expectations that adjusting the stream execution model is a significant project.  The stream implementation is highly biased towards data-parallel computations; there are hand-coded parallel implementations of all the terminal operations that reflect these biases.  There is a significant API design project, as well as an implementation project, to bring streams up to workloads with mixed data and IO parallelism.

> The opposite extreme from data-parallel is where computation of each element requires IO, such as something like:

    Stream.of(document.imagesUrls())
        .map(Url::get)
        .collect(toList());

> The current splitting heuristic is aimed at keeping the cores busy, but not oversubscribed; in the extreme IO-bound case, the resource we’re looking to keep busy-but-not-oversubscribed is IO capacity.  And if there is a mix of the two, we will want to mix accordingly.

> One might think that the answer is to have some sort of pluggable Strategy pattern to select whether to split or compute, but here the physics are not with us; the indirection costs feed into the serial fraction of Amdahl’s law, so we want to keep this computation fast.


________________________________

NOTICE: This e-mail message, together with any attachments, contains information of Clearwater Analytics and/or its affiliates that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately delete it. The information we provide is from sources Clearwater Analytics considers reliable, but Clearwater Analytics provides no warranties regarding the accuracy of the information. Further, nothing in the email should be construed as legal, financial, or tax advice, and any questions regarding the intended recipient’s individual circumstances should be addressed to that recipient’s lawyer and/or accountant.

Clearwater Analytics, 777 W. Main St, Boise, ID 83702
If you prefer not to receive emails from Clearwater Analytics you may unsubscribe<http://clearwater-analytics.com/unsubscribe>.