> 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
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.
Huh? We are spending a lot of money. (which we were doing before). However we are fixing a lot of bugs. 2024 was not that long ago, it is insane to think we might have fixed all the bugs in that time. I have personally used an LLM to fix a few long standing rare bugs that were hard to figure out. Those bugs are now gone, but there are still many more that we haven't discovered.
LLMs are a great thing for bug fixing. However they are not a miracle. You still need to do all the other things about finding, testing and fixing bugs.
You also need to care about bugs - vibe coding rarely cares about bugs.
I have a 43" Philips Ambilight (43PUS8510, 4K QLED). It's not a dumb TV per se, but you don't have to use any of the smart features, and - most important - you don't have to connect it to a network.
reply