> 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
For the past several years, Java features are released piecemeal, with each piece released as soon as it can be useful to some significant portion of users or users who can offer useful feedback (and when it's not expected to restrict future pieces). The AOT cache is already used in production despite not being as user-friendly as it could be, because the companies using it find it valuable.
The first use case is the very common one (for Java) where developers control deployment (internal deployment). The last basic building block, caching machine code, will be released next year in JDK 28, and then the feature is likely to evolve to better support other use cases, such as external deployment.
> 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.
It's normally an opt-in thing I think, since it's not an unconditional win: you have to figure out which code paths are worth it, and then where to trade off binary bloat vs the runtime cost of dynamic dispatch:
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?
Native images shouldn't be too messy anymore, Oracle put a lot of effort into DX improvements and all major web frameworks are now aware it's an important and growing use case.
Struggling to build native images should be a sign you're reliant on libraries that are dangerously outdated and abandoned.
Yes, 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.
> 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.
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
I wonder if this should trigger a warning (or even an error) at application startup whenever the CPU architectures differ.
IMHO, that would be much better than running into crashes and having to figure out the cause yourself.
Yeah, there are some strange expectations going into this.
"This is what I would like AOT cache to mean."
For the past several years, Java features are released piecemeal, with each piece released as soon as it can be useful to some significant portion of users or users who can offer useful feedback (and when it's not expected to restrict future pieces). The AOT cache is already used in production despite not being as user-friendly as it could be, because the companies using it find it valuable.
The first use case is the very common one (for Java) where developers control deployment (internal deployment). The last basic building block, caching machine code, will be released next year in JDK 28, and then the feature is likely to evolve to better support other use cases, such as external deployment.
> 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.
It's normally an opt-in thing I think, since it's not an unconditional win: you have to figure out which code paths are worth it, and then where to trade off binary bloat vs the runtime cost of dynamic dispatch:
https://doc.rust-lang.org/beta/core/arch/#dynamic-cpu-featur...
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?
Native images shouldn't be too messy anymore, Oracle put a lot of effort into DX improvements and all major web frameworks are now aware it's an important and growing use case.
Struggling to build native images should be a sign you're reliant on libraries that are dangerously outdated and abandoned.
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.
I wonder if you could do the training run on install, so that each user gets a build tied to their specific cpu?
Yes, 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.