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

[David Holmes]

On 7/10/2017 1:09 AM, 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's the same as the existing implementation. Without a specialization 
for a specific CPU the release_store_fence is just a release_store then 
a fence.

David

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