Store cpu features in AOTCodeCache header

[ashu-mehra]

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.

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed (1 review required, with at least 1 Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/leyden.git pull/84/head:pull/84
$ git checkout pull/84

Update a local copy of the PR:
$ git checkout pull/84
$ git pull https://git.openjdk.org/leyden.git pull/84/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 84

View PR using the GUI difftool:
$ git pr show -t 84

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/leyden/pull/84.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back asmehra! A progress list of the required criteria for merging this PR into premain will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 00: Full (f1dd898f)

[ashu-mehra]

@vnkozlov @adinn please take a look

[jankratochvil]

Here you test whether the new machine has at least the same CPU features as the old (stored) machine. From our experience from CRaC 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.

[adinn]

Could you provide more detail about your statement "some features presence affect ABI of the JIT-compiled code"?

[jankratochvil]

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.

[ashu-mehra]

@jankratochvil thanks for sharing your experience. It would be great if you can provide a reproducer.

[jankratochvil]

CRaC project has a similar feature. 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.

[jankratochvil]

It can be a future extension but Leyden may also find useful an equivalent of -XX:CPUFeatures=generic so that you can store the data on any machine and restore it also on any machine - limiting the CPU feature set in all runs to some reasonable minimum.