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

[Andrew Haley]

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

>> Justin King has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add back header inclusion
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Move compiler_barrier() to globalDefinitions.hpp and use it
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>
> 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.

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

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