RFR (M): 8188813: Generalize OrderAccess to use templates

[coleen.phillimore at oracle.com]

http://cr.openjdk.java.net/~eosterlund/8188813/webrev.00/src/hotspot/os_cpu/linux_aarch64/orderAccess_linux_aarch64.inline.hpp.udiff.html

+template<size_t byte_size>
+struct OrderAccess::PlatformOrderedStore<byte_size, RELEASE_X_FENCE>
+ VALUE_OBJ_CLASS_SPEC
+{
+ template <typename T>
+ void operator()(T v, volatile T* p) const { release_store(p, v); 
fence(); }
+};

Isn't release_store() removed by this patch?  Or does this call back to 
OrderAccess::release_store, which seems circular (?)

Otherwise this looks really nice.

I'll remove the *_ptr versions with 
https://bugs.openjdk.java.net/browse/JDK-8188220 . It's been fun.

Thanks,
Coleen


On 10/5/17 9:55 AM, Erik Österlund wrote:
> Hi,
>
> Now that Atomic has been generalized with templates, the same should 
> to be done to OrderAccess.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8188813
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8188813/webrev.00/
>
> Testing: mach5 hs-tier3
>
> Since Atomic already has a mechanism for type checking generic 
> arguments for Atomic::load/store, and OrderAccess also is a bunch of 
> semantically decorated loads and stores, I decided to reuse the 
> template wheel that was already invented (Atomic::LoadImpl and 
> Atomic::StoreImpl).
> Therefore, I made OrderAccess privately inherit Atomic so that this 
> infrastructure could be reused. A whole bunch of code has been nuked 
> with this generalization.
>
> It is worth noting that I have added PrimitiveConversion functionality 
> for doubles and floats which translates to using the union trick for 
> casting double to and from int64_t and float to and from int32_t when 
> passing down doubles and ints to the API. I need the former two, 
> because Java supports volatile double and volatile float, and 
> therefore runtime support for that needs to be able to use floats and 
> doubles. I also added PrimitiveConversion functionality for the 
> subclasses of oop (instanceOop and friends). The base class oop 
> already supported this, so it seemed natural that the subclasses 
> should support it too.
>
> Thanks,
> /Erik