4 ms·

The concern that jumps out at me is: what about flags that affect code generation? Some are tied to the subarch (e.g. "does this amd64 have avx2?" - relevant if

by o11c 2y ago

The concern that jumps out at me is: what about flags that affect code generation? Some are tied to the subarch (e.g. "does this amd64 have avx2?" - relevant if the cache is backed up and restored to a slightly different machine, or sometimes even if it reboots with a different kernel config), others to java's own flags (does compressed pointers affect codegen? disabling intrinsics?).

lxgr 2y ago
I don’t see any mention that code is actually going to be stored in a JITted form, so possibly it’s just architecture-independent loading and linking data being cached?
- MBCook 2y ago
  My impression from reading this was it was about knowing which classes reference which other classes when and which jars everything is in. So I think you’re right. So a bit more linker style optimization than compiler related caching stuff.
  - brabel 2y ago
    The JEP explains what this does: "The AOT cache builds upon CDS by not only reading and parsing class files ahead-of-time but also loading and linking them." While CDS (which has been available for years now) only caches a parsed form of the class files that got loaded by the application, the AOT cache will also "load and link" the classes. The ClassLoader.load method docs explain what loading means: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean) https://docs.oracle.com/en/java/javase/21/docs/api/java.base... 1. find the class (usually by looking at the file-index of the jar, which is just a zip archive, but ClassLoaders can implement this in many ways). 2. link the class, which is done by the resolveClass method: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ClassLoader.html#resolveClass(java.lang.Class) https://docs.oracle.com/en/java/javase/21/docs/api/java.base... and explained in the Java Language Specification: https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.3 https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.ht... "Three different activities are involved in linking: verification, preparation, and resolution of symbolic references." Hence, I assume the AOT cache will somehow keep even symbolic references between classes, which is quite interesting.
- ignoramous 2y ago
  From a related JEP (on AOT): https://openjdk.org/jeps/8335368 https://openjdk.org/jeps/8335368 As another possible mismatch, suppose an AOT code asset is compiled to use a specific level of ISA, such as Intel’s AVX-512, but the production run takes place on a machine that does not support that ISA level. In that case the AOT code asset must not be adopted. Just as with the previous case of a devirtualized method, the presence of AVX-512 is a dependency attached to the AOT asset which prevents it from being adopted into the running VM. Compare this with the parallel case with static compilers: A miscompiled method would probably lead to a crash. But with Java, there is absolutely no change to program execution as a result of the mismatch in ISA level in the CDS archive. Future improvements are possible, where the training run may generate more than one AOT code asset, for a method that is vectorized, so as to cover various possibilities of ISA level support in production. Also: https://openjdk.org/projects/leyden/ https://openjdk.org/projects/leyden/

by o11c 2y ago

lxgr 2y ago

I don’t see any mention that code is actually going to be stored in a JITted form, so possibly it’s just architecture-independent loading and linking data being cached?

MBCook 2y ago
My impression from reading this was it was about knowing which classes reference which other classes when and which jars everything is in. So I think you’re right. So a bit more linker style optimization than compiler related caching stuff.
- brabel 2y ago
  The JEP explains what this does: "The AOT cache builds upon CDS by not only reading and parsing class files ahead-of-time but also loading and linking them." While CDS (which has been available for years now) only caches a parsed form of the class files that got loaded by the application, the AOT cache will also "load and link" the classes. The ClassLoader.load method docs explain what loading means: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean) https://docs.oracle.com/en/java/javase/21/docs/api/java.base... 1. find the class (usually by looking at the file-index of the jar, which is just a zip archive, but ClassLoaders can implement this in many ways). 2. link the class, which is done by the resolveClass method: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ClassLoader.html#resolveClass(java.lang.Class) https://docs.oracle.com/en/java/javase/21/docs/api/java.base... and explained in the Java Language Specification: https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.3 https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.ht... "Three different activities are involved in linking: verification, preparation, and resolution of symbolic references." Hence, I assume the AOT cache will somehow keep even symbolic references between classes, which is quite interesting.
ignoramous 2y ago
From a related JEP (on AOT): https://openjdk.org/jeps/8335368 https://openjdk.org/jeps/8335368 As another possible mismatch, suppose an AOT code asset is compiled to use a specific level of ISA, such as Intel’s AVX-512, but the production run takes place on a machine that does not support that ISA level. In that case the AOT code asset must not be adopted. Just as with the previous case of a devirtualized method, the presence of AVX-512 is a dependency attached to the AOT asset which prevents it from being adopted into the running VM. Compare this with the parallel case with static compilers: A miscompiled method would probably lead to a crash. But with Java, there is absolutely no change to program execution as a result of the mismatch in ISA level in the CDS archive. Future improvements are possible, where the training run may generate more than one AOT code asset, for a method that is vectorized, so as to cover various possibilities of ISA level support in production. Also: https://openjdk.org/projects/leyden/ https://openjdk.org/projects/leyden/