RFR: 8186838: Generalize Atomic::inc/dec with templates
erik.osterlund at oracle.com
Thu Aug 31 12:45:44 UTC 2017
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
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
RBT hs-tier3, JPRT --testset hotspot
More information about the hotspot-dev