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