On Aug 8, 2018, at 1:05 PM, Martin Buchholz <martinrb@google.com> wrote:
That sounds sensible. I guess that if we use -fno-strict-aliasing then we can cast *T to *atomic<T>. I can ask on gcc@ to be sure.
A difficulty might arise if the representation of atomic<T> is different from T, as might happen if the arch has no atomic instructions for a type of that size and so a lock must be allocated somewhere. I don't know how gcc's atomic builtins deal with that problem.
A CPU/memory architecture which requires STM to for atomic storage of machine words would be a prime example of such a platform. It's also a prime example of a platform which HotSpot would not be portable to without deep refactoring along the lines of the access API but for all data. I think the two properties would be correlated, in practice. HotSpot makes pervasive assumptions that machine word data is routinely atomic (non-tearable, with valid race-winners in all cases), and it will be hard to break it of those assumptions in all cases. We've started to do that with things like the atomic, copy, and access APIs, but there's lots more to do, if we need to go down that road. — John