RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers and wrong store order in MacroAssembler [v5]

[Justin King]

On Wed, 8 Oct 2025 08:21:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> That does require including `<atomic>`, which seems not ideal in globalDefinitions. Additionally `<atomic>` will likely eventually include `<stdatomic.h>` which defines `memory_order` as well. So I think we will have to live with what is currently here.
>
> I just looked, and all of the fields in `JavaFrameAnchor` are `volatile`, so we don't need a compiler barrier on the compilers we use.

Reverted and deleted the now defunct comment pointed out by @dean-long . Only left fixing the store order in MacroAssembler and the comment in JavaFrameAnchor explaining why no hardware barriers are necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2413691111