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

[Andrew Haley]

On Tue, 7 Oct 2025 17:09:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> There are some rules about not calling the Standard C++ libraries in the Guidelines, but given that this one only prevents the compiler from moving things around and does not generate any code, I don't think that really applies. More legalisticaily-minded people might disagree, but I prefer portable code.
>
> 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.

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

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