Hacker News Reader

Comment by lazystone | Hacker News Reader

> 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.

View on HN

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.

Standard operating procedure for caches: The cache key must contain all relevant criteria to decide whether the entry contains what you want. Code for a different architecture isn't it. In a VM that might get moved around, an extended cache key would solve a lot of problems, even preserving entries for other CPUs as long as there is space.

Yea, it should probably warn and fallback to normal JIT

Should probably just kick in the JIT at that point, no?

Yeah, there are some strange expectations going into this.

"This is what I would like AOT cache to mean."

Reply on news.ycombinator.com