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