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 com

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/