> 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.
Your link is about a completely separate feature, called the AOT code cache (targeted for JDK28, not released yet). The post is about the AOT cache, which forms the foundation for this feature, but is separate and already available since JDK24. The JEP for the feature the post is about is https://openjdk.org/jeps/483
What are the most common ways to improve warmup times, actually? Looked a bunch into this, primarily native image, aot and crac, all of them super messy to get to work with a normal JVM webapp. I understand the warmup concept is inherent in JIT compilation, but how are big companies like Netflix handling this to quickly scale microservices horizontally etc?
> 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.
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.
IMHO, that would be much better than running into crashes and having to figure out the cause yourself.
"This is what I would like AOT cache to mean."
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.
https://doc.rust-lang.org/beta/core/arch/#dynamic-cpu-featur...
https://youtu.be/U2j4bKgKr-s?t=3577
Instead, this AOT feature is not very ergonomic to use at all, with too many pitfalls to be of broad use IMO.