[crac] RFR: Move CPUFeatures verification to the parent process of JVM [v3]

[Timofei Pushkin]

On Tue, 29 Apr 2025 15:12:59 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.hpp line 70:
>> 
>>> 68: 
>>> 69:   bool cpufeatures_store();
>>> 70:   bool cpufeatures_restore();
>> 
>> These can be marked `const`
>
> No longer:
> 
> crac_engine.cpp:443:32: error: passing ‘const CracEngine’ as ‘this’ argument discards qualifiers [-fpermissive]
>   443 |   switch (prepare_user_data_api()) {

I actually was imagining `prepare_user_data_api` to be called in `crac.cpp` like with the other `prepare_*_api` methods, not inside these functions. Then if we get `ApiStatus::UNSUPPORTED` we can do something else instead of failing like now.

Sorry, I forgot to write that initially: API extensions, like user data, ideally should not be mandatory, i.e. we shouldn't fail if an engine does not support an extension. In the case of CPU features I think this can be done meaningfully: if user data is not supported and `-XX:CPUFeatures` was not set we can emit a warning (not sure if only on checkpoint or also on every restore) and try to restore without verifying the features.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2067045799