RFR: 8290324: Move atomic operations outside of os_xxx.hpp [v2]

[Ioi Lam]

On Mon, 18 Jul 2022 20:51:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> It seems weird that for x86 we have `_Atomic_move_long` while for other platforms we have `atomic_copy64`. It's also odd that we have 64bit implementation of the latter but not the former, in the sense that one would expect to have both or neither.
> 
> I think all of the 64bit implementations of `atomic_copy64` are identical. I wonder if a better refactoring might be to have a shared atomic_copy64.[inline.?]hpp that has a shared 64bit implementation and uses includes platform files (using the usual macros for that) to get 32bit implementations when appropriate.
> 
> Maybe these could all be dealt with as followups.

For this PR, I just wanted to move code around but otherwise avoid making any actual changes. I'd prefer to do the further clean up in a follow up issue.

> Several of the `atomic_copy64` implementations are being moved to places where they are being given C linkage. What's the rationale for that?

That was unintentional. They just happened to be moved to immediate above the only function that uses them, and that function happens to have C linkage. Maybe I should explicitly mark these atomic_copy64 as `static inline` to be clear that whether they are C or C++ linkage is inconsequential?

-------------

PR: https://git.openjdk.org/jdk/pull/9501