Any examples of this?
> AoT languages either have to run first and compile with the profiling information to have hope of doing this...
What prevents one from JITting AoT compiled binaries?
Yes, Java and .NET.
Some JVM implementations, e.g. IBM J9, can save profile information between runs and use it for speeding up code generation, based on the complete history of the executable.
Google also started doing this when they rebooted ART into a mix of interpreter written in Assembly/JIT/AOT runtime. Starting with Android P they are even uploading profile information back to the store, so that similar devices can reach optimized AOT compiled code faster.
.NET Framework allows some control to save PGO data, and variants like that WinRT/UWP cloud compiler take it further.
> What prevents one from JITting AoT compiled binaries?
It relatively complex, versus just starting from bytecodes.
Hence why mainframes always took the approach of either JITing at installation time, or using microcoded CPUs.
Like on Burroughs, Xerox PARC and IBM cases.
If that could make it into the developer's IDE somehow, it'd be awesome. As in, the runtime detects which fields suffer from cache misses, tries a different layout, gathers data; and it all comes as fields being painted shades of blue/red in the IDE. It is one thing to have an optimized JPA object layout, but it is another to only have flat relevant data in the first place. Sort of like a database pushdown optimization through the developer, if you will.
The persistence portion you mention between runs is our AOT capability in which we are able to cache JIT method compilations on disk and load them between different JVM invocations to greatly speed up startup performance. There is a recent series of blog posts on the AOT technology in OpenJ9 in [2].
For example, an array can be specialized to hold just one datatype, or just a couple of fields, based on how it seems to be used, and then de-optimized later if the assumption is broken.