RFR: Store cpu features in AOTCodeCache header

[Jan Kratochvil]

On Fri, 4 Jul 2025 20:30:45 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This is the initial version of storing cpu features in the AOTCodeCache to verify runtime env has the same cpu capabilities as the assembly env. It covers both x86 and aarch64.
> AOTCodeCache header is updated to store the cpu features in arch-dependent form (although its same for currently supported architectures - x86 and aarch64).
> 
> It also fixes a bug - the `polling_page_vectors_safepoint_handler_blob` can be null if AVX is not present on a system. This causes crash as this blob's entry point is stored in the address table.
> I came across this when I did the assembly run with -XX:UseAVX=0 option.

CRaC project has [a similar feature](https://docs.azul.com/core/crac/cpu-features). In comparison here I miss here some command line option to disable this comparison (`-XX:CPUFeatures=ignore`) as one may find some missing CPU feature not really important to run the restored code. It is intended more for debugging/development.

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.

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

PR Comment: https://git.openjdk.org/leyden/pull/84#issuecomment-3045116578
PR Review Comment: https://git.openjdk.org/leyden/pull/84#discussion_r2190092045