LuaJIT JIT performance issues on Apple Silicon Macs

[rollerozxa]

Opening an issue for this since it's been brought up multiple times on Discord/IRC but I believe nobody has opened an issue for it yet.

On ARM-based Macs there appears to be severe performance issues with running Lua code when JIT is enabled. This forum post from slime73 over at LÖVE describes the underlying issue in more detail and links to the relevant LuaJIT issue. IIRC someone on the Discord mentioned that the performance issues do not occur on Asahi Linux, so it's only an issue when running macOS.

One possible solution would be to disable the jit in builtin and fallback to LuaJIT's interpreter, e.g. something like:

if jit and PLATFORM == "macos" and ARCH == "arm64" then
    jit.off()
end

It will be slower than the theoretical LuaJIT JIT performance but should still be faster than the PUC Lua runtime. This could alternatively also be available as a third-party mod if not put in builtin.

[sfan5]

Do we have any known concrete effects in the context of Minetest?

IIRC someone on the Discord mentioned that the performance issues do not occur on Asahi Linux, so it's only an issue when running macOS.

That sounds unlikely given the discussion in the LuaJIT issue and that the relevant jump range constant is arch-dependent, not OS-dependent.

[sfan5]

from irc:

19:58 <pgimeno> sfan5: re https://github.com/minetest/minetest/issues/14611#issuecomment-2094364044 the problem is not the jump range per se, but the failure to allocate memory that is within that range of a couple certain symbols, and that *is* OS-dependent, not just arch-dependent.
09:32 <+sfan5> pgimeno: hmmm from the issue report on the LJ repo that wasn't so clear to me 
09:35 <+sfan5> ...however people also said it affects android
09:46 <pgimeno> relevant to the memory issue: https://stackoverflow.com/questions/27945855/force-free-to-return-malloc-memory-back-to-os
09:47 <pgimeno> sfan5: yes but it appears to affect Android differently
09:58 <pgimeno> apparently the problem lies in whether the OS is able to mmap the memory within 128 MB of the critical symbols, and that's what varies with the OS
09:59 <pgimeno> (128 MB for ARM obviously)
10:06 <pgimeno> IIUC, the workaround given in the issue (using -Wl,-image_base,<somewhere far away>) works because it places the library in a virtual address that isn't surrounded by occupied addresses
10:09 <pgimeno> unfortunately it also has a side effect, which is to prevent ASLR for the LuaJIT library
11:52 <+sfan5> sounds like a possible short term workaround would be to place vm_exit_handler inside its own section?
13:01 <pgimeno> not sure how that would help, if you mean by placing them at the end then I doubt it would
16:08 <+sfan5> the section can be mapped independently with free space around it

[sfan5]

To be clear I am not against adding code like suggested in the OP post. But I'd like a bit more data first.
Perhaps someone can cook up a benchmark that has unexpectedly bad performance on macOS/ARM64?