Using C++11+ in hotspot
John Rose
john.r.rose at oracle.com
Wed Aug 8 21:16:07 UTC 2018
On Aug 8, 2018, at 1:05 PM, Martin Buchholz <martinrb at 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
More information about the workshop-discuss
mailing list