Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do.
I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.
The tradeoffs are more subtle. A JIT compiler has more timing constraint, but more information about the runtime behavior of code.
As a counter-point to your argument, consider a highly dynamic language such as JavaScript, in particular the '+' operator. An AOT compiler would have no choice but dispatch to a generic heavy implementation that could handle any possible combination of inputs. On the other hand a JIT compiler can observe the runtime values used and specialize using Inline Caches, potentially down to just a few instructions.
Probably depends on what you are optimizing for. If this metric is an app startup time then AOT is super beneficial and always beats JIT without strings attached.
Why is this being downvoted? I find it pretty clear that there is a trade off between startup time and performance. You can also observe this sort of behavior by tweaking -XX:TieredStopAtLevel when launching Java. You get marginally faster startup times but at the cost of run-time performance. And anecdotally I've seen native images start up faster but also have marginally slower runtime performance than launching a JVM and letting C2 do its thing.
It's some evidence. Perhaps the HotSpot thing outperforms AOT on its own, it could be true.
Somewhat equivalent to HotSpot but in AOT would be GraalVM's profile guided optimization. If runtime information is what brings JIT its advantage, then PGO could bring the same advantage to AOT. I don't have any hard data though.
Why is there a time limit? Doesn’t Java do multi tiered jitting with background compilation? Should be able to take as much time as needed in a background thread while code is executing in less optimized tier.
Java has 2 tiers, but even so it can’t take some unbounded amount of time doing every kind of analysis, as a big selling point of JIT compilers is optimizations based on assumptions, with some low chance of needing a de/reoptimization later.
For what its worth, there is a vendor that uses LLVM as a JIT compiler (Falcon), but that really is not the bottleneck in most java applications.
I remember trying bcc’s Java compiler years ago, and it was significantly slower than standard JITted Java, but maybe better systems exist.