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

[Justin King]

On Tue, 7 Oct 2025 14:50:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 105:
>> 
>>> 103:   __asm__ volatile ("" : : : "memory");
>>> 104: }
>>> 105: 
>> 
>> You can do this in portable C++ since C++11:
>> 
>> // Complier barrier which prevents the compiler from reordering loads and stores.
>> static inline void compiler_barrier() {
>>   std::atomic_signal_fence(memory_order_seq_cst);
>> }
>
> 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.

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

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