[crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the parent process of JVM [v11]
Timofei Pushkin
tpushkin at openjdk.org
Tue May 13 19:18:09 UTC 2025
On Tue, 13 May 2025 18:19:50 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:
>> src/hotspot/share/runtime/crac.cpp line 133:
>>
>>> 131: "with the selected CRaC engine");
>>> 132: break;
>>> 133: }
>>
>> A UX improvement: if the user asks to ignore CPU features or the platform doesn't support them the user should not see warnings/errors about the engine not being able to store them.
>>
>> Suggestion:
>>
>> if (!VM_Version::ignore_cpu_features()) {
>> VM_Version::CPUFeaturesBinary data;
>> if (VM_Version::cpu_features_binary(&data)) {
>> switch (_engine->prepare_user_data_api()) {
>> case CracEngine::ApiStatus::OK:
>> if (!_engine->cpufeatures_store(&data)) {
>> return JVM_CHECKPOINT_ERROR;
>> }
>> break;
>> case CracEngine::ApiStatus::ERR:
>> return JVM_CHECKPOINT_ERROR;
>> case CracEngine::ApiStatus::UNSUPPORTED:
>> log_warning(crac)("Cannot store CPUFeatures for checkpoint "
>> "with the selected CRaC engine");
>> break;
>> }
>> }
>> }
>
> I realized the above won't work with the current restore code: if we won't record the features because the user asked us to ignore them but the platform and engine supports them then the restore code will error because the features are not present.
>
> But without that the UX is not great and I don't really understand how `CPUFeatures=ignore` is supposed to work (it is not restore-settable but it is not used on checkpoint).
>
> So maybe it's better to change the restore code to warn instead of erroring when the features are not present (and the warning should ideally be silenceable by `CPUFeatures=ignore` or `IgnoreCPUFeatures`).
This can be postponed until the `CPUFeatures=ignore`/`IgnoreCPUFeatures` cleanup.
-------------
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087412077
More information about the crac-dev
mailing list