Yes (or something along those lines), it's just that this isn't the first use case addressed by this capability, which is being delivered gradually (as we normally do in the JDK), and not even all the basic building blocks are out yet.

That, and I think the cache busting based on CPU/environment probing logic will need to be significantly improved. Any difference in CPU features should not bust the cache; specific differences should bust the cache.

There also might be a need for "downgrading" cross-compilation profiles a la "don't compile/AOT-cache this app for the current CPU, compile/cache it for <the kind of CPU that I have 10k EC2 instances running>". You'd think that would be easier to achieve by just compiling on a production-like machine, and you'd be disappointed by the number of shops running Java apps hand-built on a Windows laptop across millions of cloud Linux cores.

You can if using Open J9, Azul, or the Android cousin, remmeber Java is not one trick pony implementation.