RFR: 8186838: Generalize Atomic::inc/dec with templates

Erik Österlund erik.osterlund at oracle.com
Mon Sep 4 10:26:44 UTC 2017


Hi Andrew,

On 2017-09-04 12:05, Andrew Haley wrote:
> On 04/09/17 10:50, Erik Österlund wrote:
>
>> As for PPC and ARMv7 though, that is not true any longer. For
>> example, our conservative memory model is more conservative than
>> seq_cst semantics. E.g. it also has "leading sync" semantics always
>> guaranteed, which is exploited in our code base and would be broken
>> if translated simply as seq_cst. Also, since the fencing from the
>> C++ compiler must be compliant with what our code generation does,
>> they could end up being incompatible due to choice of different
>> fencing conventions. Intrinsic provided operations may or may not
>> have leading sync semantics. We can hope for it, but we should never
>> rely on it.
> We can use intrinsics to get any fencing we want.


1) I want evidence for this claim. Can you get leading and trailing dmb 
sy (rather than dmb ish) for atomic operations on ARMv7?
2) Even if you could and the compiler happens to generate that - we can 
not rely on it because there is no contract to the compiler what fence 
instructions it elects to use. The only contract the compiler needs to 
abide to is how atomic C++ operations interact with other C++ 
operations. And we do not want the underlying fencing to silently change 
when performing compiler upgrades.

Thanks,
/Erik


More information about the hotspot-dev mailing list