RFR: 8367717: Cleanup atomic_copy64 [v2]

[Kim Barrett]

On Wed, 8 Oct 2025 12:29:42 GMT, Justin King <jcking 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.
>> 
>> @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?

@jcking I think AtomicAccess mostly already has platform-specific specializations.  A case where it doesn't
is the bitops, but there we have a default naive implementation, with the intent that platforms will (eventually)
specialize. There's one of those efforts being reviewed now (for ppc).

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

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