RFR: 8325821: [REDO] use "dmb.ishst+dmb.ishld" for release barrier

[kuaiwei]

On Mon, 25 Mar 2024 06:54:01 GMT, kuaiwei <duke at openjdk.org> wrote:

> The origin patch for https://bugs.openjdk.org/browse/JDK-8324186 has 2 issues:
> 1 It show regression in some platform, like Apple silicon in mac os
> 2 Can not handle instruction sequence like "dmb.ishld; dmb.ishst; dmb.ishld; dmb.ishld"
> 
> It can be fixed by:
> 1 Enable AlwaysMergeDMB by default, only disable it in architecture we can see performance improvement (N1 or N2)
> 2 Check the special pattern and merge the subsequent dmb.
> 
> It also fix a bug when code buffer is expanding, st/ld/dmb can not be merged. I added unit tests for these.
> 
> This patch still has a unhandled case. Insts like "dmb.ishld; dmb.ishst; dmb.ish", it will merge the last 2 instructions and can not merge all three. Because when emitting dmb.ish, if merge all previous dmbs, the code buffer will shrink the size. I think it may break some resumption and think it's not a common pattern.

update: I added finite state machine for merging instruction. The patch can be found in https://github.com/openjdk/jdk/commit/1b18e8298b1ef8778b494fb7ed9e4467e0a9a6b8 . Because instructions are pending, I need modify Assembler::pc() and offset() to count the pending instruction size. It may impact relocation. I fixed some failure and still some test failure to be figure out. I'm working on them.

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

PR Comment: https://git.openjdk.org/jdk/pull/18467#issuecomment-2030964309