Current implementation of CPU features check compare the whole buffer of cpu features. This could introduce a potential issue when CPU features accumulate.

Consider this example.
If at JDK version X there are 5 CPU features, they are a(0), b(1), c(2), d(3), e(4), the number inside () is the feature index assigned (it could be explicitly or implicitly, depends on the implementation of VM_Version). In the future at JDK version Y there could be another feature f added, but f could be added at the middle of features list (reason could be to group some features together or order all cpu features in alphabetical way, so now it looks like a(0), b(1), c(2), f(3), d(4), e(5).
So, cpu features buffer of the version X in an archive could be 111110000..., which means all 5 features (a/b/c/d/e) are supported, and this archive could be used by a runtime of version Y, and the local CPU supports a/b/c/f/d, but not e, in this situation, the cpu features are also 111110000..., which means buffer comparison result is equal, but indeed they are not equal.

The solution could be just introduce an cpu_feature_number, before comparing the buffer, compare if the number is equal, if not just fail the cpu feature comparison.
This solution is based on the assumption that we only add but not remove CPU features.