Hacker News

points by lazystone 16 hours ago | 0 comments

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

[–] crschnick 16 hours ago

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

[–] florieger 16 hours ago

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.

[–] ahartmetz 1 hour ago

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.

[–] odo1242 14 hours ago

Yea, it should probably warn and fallback to normal JIT

[–] jayd16 15 hours ago

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

[–] paulddraper 16 hours ago

Yeah, there are some strange expectations going into this.

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