RFR: 8186838: Generalize Atomic::inc/dec with templates

[Andrew Haley]

On 04/09/17 08:15, Erik Österlund wrote:
> Having said that - I am not opposed to simply removing the
> specializations of inc/dec if we are scared of the complexity of
> passing this constant to the platform layer.

It isn't exactly about fear, but of course we should be cautious about
adding complexity.  Simplicity is prerequisite for reliability.
[One of Dijkstra's pithiest comments.]

> After running a bunch of benchmarks over the weekend, it showed no
> significant regressions after removal.  Now of course that might not
> tell the full story - it could have missed that some critical
> operation in the JVM takes longer. But I would be very surprised if
> that was the case.

Good.  So would I.

Fred Brooks distinguishes between two types of complexity: accidental
and essential. Essential complexity is determined by the problem to be
solved, and nothing can remove it.  Accidental complexity is caused by
the implementation: programming language, use of assembly code, and so
on.

In this case, the idea of atomically incrementing a variable is
extremely simple.  It's barely even worthy of the name "algorithm".  I
believe that almost all of the complexity of a solution is accidental:
it's mostly caused by C++, the C++ compilers we use, and the internal
conventions of HotSpot.  The question in my mind is: how much of the
accidental complexity can we remove?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671