RFR (M): 8184334: Generalizing Atomic with templates
erik.osterlund at oracle.com
Tue Jul 18 09:40:45 UTC 2017
Thank you for checking this.
On 2017-07-18 11:13, Thomas Stüfe wrote:
> Hi Eric, Volker,
> builds fine on AIX 5.3 and 7.1.
> gtests show no errors.
> Kind Regards, Thomas
> On Fri, Jul 14, 2017 at 6:28 PM, Erik Österlund
> <erik.osterlund at oracle.com <mailto:erik.osterlund at oracle.com>> wrote:
> The Atomic class mostly uses the JNI-specific j-types (jbyte,
> jshort, jint, jlong). This has led to wide-spread pollution of
> j-types in the C++ code base.
> Another problem is that when dealing with certain inherently not
> j-typed types like pointers, hacks were built that allowed them
> using _ptr member functions that had to be specialized on every
> architecture supported by Java.
> Yet another problem is yet another exception, like size_t, that
> does not quite fit being a pointer and isn't necessarily mapped to
> any j-type. Then yet more exceptions were built on top. And what
> about intx? You get the idea by now.
> As a remedy to the above mentioned problems, I propose to
> generalize the Atomic implementation to use templates instead.
> The new Atomic API handles pointers, all integer and floating
> point types that the underlying architecture supports.
> To achieve this, a new metaprogramming tool called IntegerTypes
> was built, that allows us to safely cast between different
> integral, floating point and pointer types of the same size while
> preserving the bit pattern of the values. This allows Atomic to
> take primitive types and canonicalize them to the same integer
> type that is passed to the platform layer.
> As for atomic operations on integral types like add/inc/dec,
> pointer scaling is now performed. That is, the functional
> behaviour is modelled after the +=, ++ and -- operators
> correspondingly. The X_ptr member functions have been deprecated,
> but are still there and can be used with identical behaviour as
> they had before. But new code should just use the non-ptr member
> functions instead.
> The platform layer specializes the specialized_X member functions
> that take canonicalized signed integers as input, and turn them to
> some platform-specific instruction sequence.
> A nice benefit with these changes is that the platform-specific
> code has gotten a lot of pointless redundancies removed such as
> how to perform atomic loads and stores on native word or less
> sized integers, or having inc/dec implementations that just reuse add.
> As for testing, new gtests were written for IntegerTypes as well
> as Atomic to make it more convincing that the functional behaviour
> Apart from that, I have run JPRT, JTREG, RBT hs-tier3 and a few
> local tonga test lists including nsk.jdi, nsk.monitoring,
> nsk.stress, vm.gc on Solaris SPARC T7-4 and Linux AMD64.
> As for oracle-external ports, I would appreciate if port
> maintainers could check if it seems to make sense. I have done my
> best to try to make the appropriate changes where needed.
> Special thanks go to Kim Barrett that has worked closely with me
> on this and whom I exchanged many emails with, and so I would like
> him to be a co-author.
More information about the hotspot-runtime-dev