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

[Erik Österlund]

Hi everyone,

Bug ID:
https://bugs.openjdk.java.net/browse/JDK-8186838

Webrev:
http://cr.openjdk.java.net/~eosterlund/8186838/webrev.00/

The time has come for the next step in generalizing Atomic with 
templates. Today I will focus on Atomic::inc/dec.

I have tried to mimic the new Kim style that seems to have been 
universally accepted. Like Atomic::add and Atomic::cmpxchg, the 
structure looks like this:

Layer 1) Atomic::inc/dec calls an IncImpl()/DecImpl() function object 
that performs some basic type checks.
Layer 2) IncImpl/DecImpl calls PlatformInc/PlatformDec that can define 
the operation arbitrarily for a given platform. The default 
implementation if not specialized for a platform is to call Atomic::add. 
So only platforms that want to do something different than that as an 
optimization have to provide a specialization.
Layer 3) Platforms that decide to specialize PlatformInc/PlatformDec to 
be more optimized may inherit from a helper class 
IncUsingConstant/DecUsingConstant. This helper helps performing the 
necessary computation what the increment/decrement should be after 
pointer scaling using CRTP. The PlatformInc/PlatformDec operation then 
only needs to define an inc/dec member function, and will then get all 
the context information necessary to generate a more optimized 
implementation. Easy peasy.

It is worth noticing that the generalized Atomic::dec operation assumes 
a two's complement integer machine and potentially sends the unary 
negative of a potentially unsigned type to Atomic::add. I have the 
following comments about this:
1) We already assume in other code that two's complement integers must 
be present.
2) A machine that does not have two's complement integers may still 
simply provide a specialization that solves the problem in a different way.
3) The alternative that does not make assumptions about that would use 
the good old IntegerTypes::cast_to_signed metaprogramming stuff, and I 
seem to recall we thought that was a bit too involved and complicated.
This is the reason why I have chosen to use unary minus on the 
potentially unsigned type in the shared helper code that sends the 
decrement as an addend to Atomic::add.

It would also be nice if somebody with access to PPC and s390 machines 
could try out the relevant changes there so I do not accidentally break 
those platforms. I have blind-coded the addition of the immediate values 
passed in to the inline assembly in a way that I think looks like it 
should work.

Testing:
RBT hs-tier3, JPRT --testset hotspot

Thanks,
/Erik