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

Andrew Haley aph at openjdk.org
Tue Oct 7 14:47:40 UTC 2025


On Tue, 7 Oct 2025 14:07:29 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> 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);
}

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

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


More information about the hotspot-dev mailing list