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

[Doug Lea]

On 01/06/13 15:25, Martin Buchholz wrote:

> Yes, j.u.c.-java is hard to read due to extreme performance orientation and
> need to save reads in locals everywhere, and pretty far from java
> programmer mainstream.

(I'm going to stay out of further general style discussions
beyond saying that when people ask me what I program in, I
say "JVMese", not Java  :-)

>
> I'm also looking at LongAccumulator.accumulate(long).
>
> - shouldn't "function" also be pulled into a local?

No need: it is typically used only once per call.

> - Why "as"?  Why not "cs"?  Did Cell once have a name beginning with "A"?

Yes, and probably will again when we can use @Contended form of AtomicLong.

> - (m = as.length - 1) < 0  ?? as.length should always be >= 2, so this
> check should be redundant.  Or is this to help hotspot elide NPE throw code?

Yes; this pushes almost all checks into slow path.

> - Why not push most of this method into Striped64, as in

Lots and lots of profiling/testing suggests that this is the
best compromise form.

The basic performance challenge here is that we want to use
no more than the cost of a failed CAS taking an alternate
path. The path that does this doesn't look as fast as it
is; we seem to be within 10% of ideal
zero-contention-per-update performance, at vastly less
space consumption. We might get even closer than that sometime.


-Doug