For more on the difference, and an explanation of what JIT is, check out this section of the book Crafting Interpreters (https://craftinginterpreters.com/a-map-of-the-territory.html...)
It is heavily based around tail calls. I recently wrote a blog article about how we applied a similar tail-call-oriented strategy to accelerate protobuf parsing to 2+GB/s: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
I also recently landed a change in Clang trunk that offers guaranteed tail calls, so that this tail call design is safe in non-opt builds: https://reviews.llvm.org/D99517 I think wasm3 could benefit from using this attribute when it is available.
These rules guarantee that the tail call is possible to perform on every platform. They end up being more strict than is necessary on some platforms and calling conventions.
Do none of the notable ones do normal compilation?
If the environment you run on doesn’t support JIT compilation (iOS for example), AOT compiling WASM is useful.
In what way does a platform need to coöperate with that?
To support that, the environment must allow the JIT to write machine code to memory, and then execute that same code.
CPUs have memory protection flags to control which memory areas can be written, and which can be executed. The OS is in charge of setting those flags, on request from the application. Eg. mmap and mprotect system calls.
iOS denies requests for memory that is both writable and executable at the same time. So applications cannot get the type of memory area a JIT needs. There are indirect methods where a file is written then mapped, like generating a small program or shared library on the fly. But iOS restricts these as well.
There are workarounds for a developer's personal applications, used on their own registered iOS devices. But these workarounds cannot be run by everyone else, except people with a jailbroken iOS. They cannot be used in applications on the App Store.
https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
> The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on. These steps are similar to what you’d do to run C/C++ applications in the browser, but we’re performing the wasm to native code translation ahead of time, when Firefox itself is built.
It's a middle ground between sandboxing with subprocesses (which adds all the overhead of IPC) and switching to a fully memory-safe language (Rust, JS, etc.)
But even with the broad definition of JIT, one important difference is that AoT compilers don't have to mark pages executable.
But in general you can't "just compile" Webassembly, because you need a runtime.
There is a C project that can compile an executable that includes the runtime and the compiled WASM, but the name is escaping me right now.
Note that JIT in the WASM world doesn't quite mean the same thing as for eg Java. Almost all runtimes compile a whole module at once, not individual functions.
Full AoT compilation, C programs run within 10% of native
Lost information about e.g. aliasing?
https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html