From the review of JDK-8290324 by [~kbarrett] (https://github.com/openjdk/jdk/pull/9501)

[1] 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.

[2] inline void atomic_copy64(const volatile void *src, volatile void *dst) {
    *(jlong *) dst = *(const jlong *) src;

s/jlong/uint64_t/ (or int64_t). And casting away volatile seems kind of sketchy. This could be

   Atomic::store((uint64_t*)dst, Atomic::load((const uint64_t*)src));

which seems clearer to me.

[3] src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp:

template<>
template<typename T>
inline T Atomic::PlatformLoad<8>::operator()(T const volatile* src) const {
  STATIC_ASSERT(8 == sizeof(T));
  volatile int64_t dest;
  os::atomic_copy64(reinterpret_cast<const volatile int64_t*>(src), reinterpret_cast<volatile int64_t*>(&dest));

Why do we have these casts when atomic_copy64 takes volatile void*? (There are more like this)

[4] src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
  void _Copy_conjoint_jlongs_atomic(const jlong* from, jlong* to, size_t count) {
    if (from > to) {
      const jlong *end = from + count;
      while (from < end)
        os::atomic_copy64(from++, to++);
        atomic_copy64(from++, to++);

If atomic_copy64 was a shared API with platform-specific implementations we could eliminate all these copies of _Copy_conjoint_jlongs_atomic.