RFR (M): 8184334: Generalizing Atomic with templates

[Erik Österlund]

Hi,

Bug:
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/~eosterlund/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