RFR (M): 8184334: Generalizing Atomic with templates

[Erik Österlund]

Hi Thomas,

Thank you for checking this.

/Erik

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:
>
>     Hi,
>
>     Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8184334
>     <https://bugs.openjdk.java.net/browse/JDK-8184334>
>     <https://bugs.openjdk.java.net/browse/JDK-8184334
>     <https://bugs.openjdk.java.net/browse/JDK-8184334>>
>
>     Webrev:
>     http://cr.openjdk.java.net/~eosterlund/8184334/webrev.00/
>     <http://cr.openjdk.java.net/%7Eeosterlund/8184334/webrev.00/>
>     <http://cr.openjdk.java.net/~eosterlund/8184334/webrev.00/
>     <http://cr.openjdk.java.net/%7Eeosterlund/8184334/webrev.00/>>
>
>     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
>     works.
>     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.
>
>     Thanks,
>     /Erik
>
>