| This is all true, but there's another angle that often gets missed: JITs are really only ideal for request-processing systems, in which a) memory is abundant b) the same code paths run over and over and over again, and c) good p99 latency is usually the bar. In contrast, in user facing apps, you usually find that a) memory is constrained b) lots of code runs rarely or in some cases once (e.g. the whole start-up path) c) what would be considered good p99 latency for a server can translate to pretty bad levels of jank. JITs can't do anything if the code you care about runs rarely and causes a frame skip every time you hit it, either because the JIT hasn't triggered yet due to too-few samples, or the generated code has been evicted from the JIT cache because you don't have memory to spare. And if you have code that needs to run fast _every_ time it runs, the easiest way to do that is to start with fast code already compiled and ready to execute. We saw this play out when android moved from Dalvik (JIT) to ART (AoT compilation). Apple figured this out years earlier. Of course it's not that there are no highly performant apps built on JIT runtimes. But it's a significant headwind. (Most of the above applies equally to tracing GC, btw) |
Also that Android followed up on Windows Phone model, their mistake was making the AOT compilation on the phone instead of on the store like Windows Phone was doing.
JITs are very capable, provided people also design with them in mind.
The clever Apple with AOT failed against this now famous benchmark, against tracing GC languages, using a JIT.
https://github.com/ixy-languages/ixy-languages