[crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo, 0xbar on checkpoint [v5]

[Timofei Pushkin]

On Sat, 31 Jan 2026 12:39:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
>> 
>> 
>> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
>> 
>> 
>> is wrong as it does not do logical and of both CPUFeatures masks.
>> 
>> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
>> 
>> @rvansa will probably want to change the API but this is a PoC how it should work.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get_failed_bitmap to return stored data

src/hotspot/share/runtime/crac_engine.cpp line 514:

> 512:         image_features &= *datap;
> 513:       }
> 514:       log_error(crac)("Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=%s on checkpoint.", image_features.print_numbers());

In the exact case with this wording I believe `datap` should be printed, not `image_features`. Maybe it's a good idea to rename `datap` to `current_features` to avoid confusion, and also make it a reference instead of a pointer.

src/java.base/share/native/libcrexec/image_constraints.cpp line 291:

> 289:       print_bitmap("Image:        ", static_cast<const unsigned char*>(t->data), t->data_size);
> 290:       free((void *) c.image_data);
> 291:       c.image_data = static_cast<unsigned char *>(malloc(c.data_size));

Allocation should be checked for success

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

PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2752938807
PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2752921227