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

[Kim Barrett]

On Sat, 16 Jul 2022 01:28:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The os_xxx.hpp files inject extra methods/fields that are specific to atomic operations into the `os` class. However, the injected methods/fields are used only by a specific os/cpu combination. Therefore, they should not be inside the `os` class, which should contain only APIs that are used across platforms.
>> 
>> - For ports where the `atomic_copy64()` function is used in a single file, I moved it as an inline function in that file
>> - Otherwise it's moved to `atomic_<os>_<cpu>.hpp`
>> - The linux/arm port is a little more involved, but the new code should be a little cleaner than the old code.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8290324-move-atomic-ops-outside-os-hpp
>  - 8290324: Move atomic operations outside of os_xxx.hpp

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.

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

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

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