RFR: Store cpu features in AOTCodeCache header

Jan Kratochvil jkratochvil at openjdk.org
Mon Jul 7 16:21:07 UTC 2025


On Mon, 7 Jul 2025 13:45:27 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 797:
>> 
>>> 795: bool VM_Version::supports_features(void* features_buffer) {
>>> 796:   uint64_t features_to_test = *(uint64_t*)features_buffer;
>>> 797:   return (_features & features_to_test) == features_to_test;
>> 
>> Here you test whether the new machine has at least the same CPU features as the old (stored) machine. From our experience from [CRaC](https://docs.azul.com/core/crac/cpu-features) one should rather compare the features are equal. As some features presence affect ABI of the JIT-compiled code and if the new machine has such CPU features the newly JITted code will be incompatible with ABI of the stored code cache.
>
> Could you provide more detail about your statement "some features presence affect ABI of the JIT-compiled code"?

Simply said if you store the compiled Java code on old CPU (almost no features) and then run it on new CPU (full features) then it will crash. It crashes when a newly compiled code calls the restored code or vice versa. If you disagree I can try to reproduce with Leyden, it was happening with CRaC.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/84#discussion_r2190526357


More information about the leyden-dev mailing list