RFR (M): 8184334: Generalizing Atomic with templates

[Thomas Stüfe]

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>
wrote:

> 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