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:

>> 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?

I have created a new JBS issue ( https://bugs.openjdk.org/browse/JDK-8290745 - Refactor atomic_copy64() functions ) to capture @kimbarrett's comments on the various problems with the atomic copying functions.

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

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