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
