RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
dl at cs.oswego.edu
Sun Jan 6 21:15:23 UTC 2013
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.
More information about the core-libs-dev