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

[Erik Österlund]

Hi Andrew,

On 2017-09-04 12:41, Andrew Haley wrote:
> On 04/09/17 11:26, Erik Österlund wrote:
>> 1) I want evidence for this claim. Can you get leading and trailing dmb
>> sy (rather than dmb ish) for atomic operations on ARMv7?
> I hope not.  There is no reason for us to want such a thing in HotSpot.
> But even if we did want such a thing, we could crop down to asm: the
> point is the usual cases, not weird corner cases.

So we can not emit any fencing we want with GCC intrinsics, let alone 
the fencing we already have and rely on today on ARMv7. The discussion 
about whether we should relax our ARMv7 fencing or not is a different 
discussion, and is unrelated to the claim that we can get any fencing we 
want with GCC intrinsics. The point is that we can not control the 
fencing arbitrarily, let alone even get the fencing we have today.

>> 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.
> There is no way that GCC writers would break ABI compatibility in such a
> fundamental way.  There would be a firestorm.  I know this because even
> if no-one else started the fire, I would.  I am a GCC author.

Thank you for your reassurance. I appreciate that you take ABI 
compatibility seriously. Yet over the years, the bindings have changed 
over time as our understanding of implications of the memory model has 
evolved - especially when mixing stronger and weaker accesses on the 
same fields. Even 2017, there are still papers published about how 
seq_cst mixed with weaker memory ordering needs fixing in the bindings 
(cf. "Repairing sequential consistency in C/C++11", PLDI'17), resulting 
in new bindings with both leading sync and trailing sync conventions 
being proposed (the choice of convention is up to compiler writers). I 
do not feel confident we can rely on these bindings never changing. As 
there is no contract or explicit ABI, compiler writers are free to do 
whatever that is consistent within the boundaries of C++ code and the 
C++ memory model. The actual ABI is hidden from that contract. And I 
would not happily embed reliance on intentionally undocumented, 
implicit, unofficial ABIs that are known to have different fencing 
conventions that may or may not be compatible with what our generated 
code requires. Generating the code, disassembling, and then assuming 
whatever binding was observed in the disassembly is a binding contract, 
is not a reliable approach.

If we require a specific fence, then I do not see why we would not 
simply emit this specific fence that we require explicitly, rather than 
insisting on using some intrinsic and hoping it will emit that exact 
fence that we rely on through some implicit, undocumented, unofficial 
ABI, that may silently change over time. I fail to see the attraction.

Thanks,
/Erik