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

[Andrew Haley]

On Mon, 8 Apr 2024 11:58:22 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:
>> After discussion, I made a new implementation based on finite state machine for merging instruction. The mergeable instruction will be pending in fsm until next unmergeable instruction.
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cross build error

So I had another thought. I think it'd be easier, and more robust, if you kept the contents of the code buffer valid at all times, and transition the state machine to its initial state whenever there is any attempt to get `CodeBuffer::offset()`. That would also minimize the impact of this patch on the rest of the code. You can always back up when you see something like `dmb st; dmb ld; dmb ish`.

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

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