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

[Erik Österlund]

Hi Coleen,

On 2017-10-06 17:09, coleen.phillimore at oracle.com wrote:
> 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 (?)

It is as David says. This does the same as was done before.
Without this specialization, release_store_fence() would turn into 
release() store() fence(). This specializes further with release_store() 
fence(), which will probably turn into stlr; dmb ish; with GCC 
intrinsics on AArch64, which is a bit more slim than release() store() 
fence() which would use more fencing.

> Otherwise this looks really nice.

Thank you!

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

Thanks for doing that Coleen.

/Erik

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