RFR: 8367717: Cleanup atomic_copy64 [v2]

[Justin King]

On Tue, 7 Oct 2025 01:28:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`.  I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR.
>
>> This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR.
> 
> @jcking - I noticed that problem too, while reviewing this change. I don't care
> whether it is fixed in this PR or in yours.
> 
> Note that your's currently doesn't perform atomic accesses on the "from"
> value. I think that's wrong, since the documentation for these functions
> doesn't indicate atomicity only for the store.  The comment in copy.hpp says
> "atomicity: atomic or non-atomic on the copy unit." I take that to mean both
> source and destination.
> 
> Your PR is also not addressing other platforms with similar issues, such as in
> copy_ppc.hpp. 
> 
> Also, this all begs the question of why we have four different copies of these
> functions - bsd_aarch64, bsd_zero, linux_aarch64, and linux_zero. All of these
> should be identical.
> 
> Basically, I think the Copy class is kind of a mess, and that discourages its
> use. Probably this needs an overall plan of attack (broken up into reviewable
> chunks, but with an overarching goal), rather than piecemeal fixups.

@kimbarrett 

Proposal, should we do something similar to AtomicAccess? Provide default naive implementations and let each platform specialize?

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

PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3381289286