RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]

[Evgeny Astigeevich]

On Mon, 21 Jul 2025 16:25:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655)
>>> 
>>> Frederick (@fbredber) wanted to avoid branches: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740)
>> 
>> You're getting branches, one way or the other.
>
> I actually like the compiler version, especially if we lay out enums in some sane order. In current inline assembly, adding a new case makes some branches _longer_; probably irrelevant on this small scale, but still. With compiler-compiled switch, we effectively get new additions like `SB` for "free", as every other label stays in place.

I put cases in enum order. On my M3 Pro I get:

libjvm.dylib[0x8a75e8] <+0>:   stp    x29, x30, [sp, #-0x10]!
libjvm.dylib[0x8a75ec] <+4>:   mov    x29, sp
libjvm.dylib[0x8a75f0] <+8>:   adrp   x8, 1417
libjvm.dylib[0x8a75f4] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
libjvm.dylib[0x8a75f8] <+16>:  ldr    w8, [x8]
libjvm.dylib[0x8a75fc] <+20>:  cmp    w8, #0x1
libjvm.dylib[0x8a7600] <+24>:  b.gt   0x8a7620       ; <+56> at os_bsd_aarch64.cpp:534:5
libjvm.dylib[0x8a7604] <+28>:  cbz    w8, 0x8a7640 ; <+88> at os_bsd_aarch64.cpp:538:7
libjvm.dylib[0x8a7608] <+32>:  cmp    w8, #0x1
libjvm.dylib[0x8a760c] <+36>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
libjvm.dylib[0x8a7610] <+40>:  isb
libjvm.dylib[0x8a7614] <+44>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7618] <+48>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a761c] <+52>:  ret
libjvm.dylib[0x8a7620] <+56>:  cmp    w8, #0x2
libjvm.dylib[0x8a7624] <+60>:  b.eq   0x8a7650       ; <+104> at os_bsd_aarch64.cpp:544:7
libjvm.dylib[0x8a7628] <+64>:  cmp    w8, #0x3
libjvm.dylib[0x8a762c] <+68>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
libjvm.dylib[0x8a7630] <+72>:  sb
libjvm.dylib[0x8a7634] <+76>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7638] <+80>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a763c] <+84>:  ret
libjvm.dylib[0x8a7640] <+88>:  nop
libjvm.dylib[0x8a7644] <+92>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7648] <+96>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a764c] <+100>: ret
libjvm.dylib[0x8a7650] <+104>: yield
libjvm.dylib[0x8a7654] <+108>: mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7658] <+112>: ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a765c] <+116>: ret


It's interesting. My code is binary search tree version.
It does not depend on the order of the cases. 
I could not get jump table version you've got.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2220438239