Hi guys
I’m unable to build Erlang 27.0.1 from source with JIT enabled on macOS intel chip.
I found this old related Elixir thread where someone said that a fix should be available when Erlang 27.x will be released.
N.B: on my macOS M1, there’s no issue at all and JIT is enabled.
Thanks for your help
You will need to explicitly enable JIT support when building:
% ./configure --enable-jit
The reason that the JIT is disabled by default on Intel Macs is that it will cause annoying pop-up windows on macOS Sonoma.
@bjorng Strange because I’ve Erlang 26.2.1 which I’ve built from source before updating my macOS (x86_64) to Sonoma and I don’t get this annoying pop-up:
Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns] [dtrace]
Eshell V14.2.1 (press Ctrl+G to abort, type help(). for help)
And as you can see, JIT is enabled. Same for Erlang 25.3.24 + 24.2.1. They all work as expected with JIT enabled.
Let me try rebuild 27.0.1 with --enable-jit flag.
@bjorng it worked and I can see JIT enabled now 
.
$ sw_vers | head -2
ProductName: macOS
ProductVersion: 14.5
$ uname -m
x86_64
$ erl
Erlang/OTP 27 [erts-15.0.1] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns] [dtrace]
But I don’t have any annoying pop-up. When does it appear?
I haven’t seen it myself; I’ve newer owned an Intel Mac that can run Sonoma. I don’t remember who reported it or where.
Since you don’t see those pop-ups, I assume it happens only in specific circumstances. It could be that it happens when the hardened runtime is enabled (which is a requirement for notarization).
@bjorng thanks for the feedback.
One last question: why on macOS intel it says [jit:ns] and on macOS M1 it says only [jit]?
ns indicates that the native stack mode is used; that is, generated native code will use the CPU’s stack pointer register to keep track of the BEAM stack. That is the most efficient way to handle the stack and is therefore the default. In some circumstances, it is not possible to use the native stack (I’m being deliberately vague here, because I don’t remember the details), and therefore there exists another way to build the system that will use another CPU register to keep track of the BEAM stack.
With an AArch64/ARM64 CPU, there is only one way to handle the stack pointer, so there is no need for any mode indicator. (The native stack pointer register is not used for the BEAM stack, because that is not really possible on AArch64 given how the BEAM stack is organized. Fortunately, not using the native stack pointer register has much less of a performance penalty for an AArch64 CPU compared to not using it on an x86_64 CPU.)
@bjorng Thanks a lot.