I wonder if you could do the training run on install, so that each user gets a build tied to their specific cpu?

> In theory, the whole AOT cache idea sounds like something that should only affect the class data and not perform any native compilation

https://openjdk.org/jeps/544

> Non-Goals

> It is not a goal to support cross-compilation. Code compiled in a training run must run on the same CPU architecture, with the same set of features, in subsequent production runs.

The Inside Java podcast episode on AOT caching covers the issue in this segment:

https://youtu.be/U2j4bKgKr-s?t=3577

When AOT came to be, I kinda hoped for GraalVM's solution would make it relatively as-is to open jdk.

Instead, this AOT feature is not very ergonomic to use at all, with too many pitfalls to be of broad use IMO.

> What would be needed is some sort of compatibility switch that disables all optional CPU features. Sure, you will get some reduced performance of the compiled code, but in exchange, a faster startup time.

I think other AOT-compiled languages don't opt in for the lowest set of CPU features -- they just detect them at runtime and use whenever present, all in compiled machine code.