.Net has the same issue and MS also went this route for Windows phone and it's now making its way to the desktop.
If it can be done at build time it should, I think everyone is realizing that on many fronts. Long startup times and battery power being consumed by a jit is a worse users experience.
Caching first-run still gives you the ability to do more/new profiled-based optimization later.
Jitted languages are not known for their performance, they are faster than interpreted ones and slower than the AOT ones generally speaking. So what performance benefit did jit bring compared to a good AOT compiler?
You've gone through the JIT process of live profiling, hot spot detection, compiled down to native code etc. etc., then saved it along the way so that next launch you can start fast with everything already optimised (but also in a position to continue to learn and improve should the opportunity arrive.)
Your first run or two will be slower, beyond that you should be as fast as your code will go.
You have to pay for profile guided optimization. That optimizer is another program running on your CPU. It needs memory, time slices, access to secondary storage, etc. It's worth it only if the user code can be improved so much that the total of the two is smaller than what you would have gotten by just compiling it once. And that's not easy to do for general purpose computation.
What is the difference between AOT and sufficiently aggressive JIT caching?
> Caching first-run still gives you the ability to do more/new profiled-based optimization later.
Well you could have your runtime running with the overhead of an interpreter, a profiler, and an optimizer, and hope all will turn out well. Or you could just run the machine code without these complexities and know that it is probably close to optimal anyway.
AoT doesn't adapt to changing program profiles.
Do you have any sources on that? Java 8 has been released for a while now, and this is the first time I hear about this.
Given the dynamism of most Java code and the very very wide use of runtime-generated code via cglib or asm, dynamic proxies etc., I think this could actually be quite hard (well, the runtime could still cache the generated code, and if the dynamically generated bytecode matches the stored hash, it could just use the cached code; but maybe there are other issues as well).