RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

[Aleksey Shipilev]

On 01/14/2013 06:38 PM, Peter Levart wrote:
> I think these classes are targeted at use cases such as gathering 
> real-time statistics of profiling or business data, where data comes in 
> from various sources in real-time and statistics are sampled in 
> real-time too...
> 
> For bulk processing, the new streams API seems more appropriate. I think 
> the user might be able to control the order of operations applied 
> (j.u.stream.Spliterator API indicates that the spliting of work among 
> FJP threads could be controled and we can hope that the order of 
> reduction of intermediary results would also be controllable by the user 
> or at least defined).
> 
> Can streams API developers shed some light on that?

I'm a bit on both camps here; and have a different perspective.

*Adders are suited for the cases when the threading is already out of
control, i.e. you can not guarantee any particular order in which
threads are calling the public methods. *Adders are the best thing you
can do at this point (I'm not sure you can do better theoretically).
There are remarkably large number of scenarios where you can find these
useful; basically everywhere where you clearly have add/get ratio
considerably high.

Streams API, on the other hand, is at the explicit control of it's
internal threading, and so Collectors [1] would be beating *Adders on
most scenarios, because these accumulate() computation tree leaves
thread-locally, and then combine() across the leaves. In fact, that
pushed our internal performance tests from using *Adders as the way to
safely reduce across parallel pipeline to more concise Collectors.

HTHS,
-Aleksey.

[1]
http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collector.java