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

[Justin King]

On Mon, 6 Oct 2025 16:19:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.
>
>> Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.
> 
> Threads always see their own stores in program order, so no, we don't need store barriers.

Okay, updated the PR and issue. Removed the existing unnecesary barriers and just fixed the program order store issue in `MacroAssembler::set_last_Java_frame` to set `sp` last.

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

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