[crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine

[Radim Vansa]

On Wed, 1 Oct 2025 08:48:16 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Right now the logic checking if CPU features used before checkpoint match current CPU features is in VM code. VM stores and retrieves CPU features through C/R API's user_data extension. This is convenient when we have a single image that can be either accepted or rejected, but does not offer the flexibility for C/R engine to select the best image for current execution environment.
>> 
>> The goal of this issue is to move to a declarative API that will express the requirements using more abstract means, labels (for CPU architecture) and bitmaps (for CPU features).
>
> src/hotspot/share/include/crlib/crlib.h line 85:
> 
>> 83: #define RESTORE_ERROR_INVALID   -4 // image is not suitable (e.g. corruption or wrong architecture)
>> 84: #define RESTORE_ERROR_MEMORY    -5 // memory allocation failure during restore
>> 85: #define RESTORE_ERROR_PROCINFO  -6 // the process cannot fetch information about itself
> 
> Cannot it be an enum?

The API already defines return value as `int`, we don't want to change that part.

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

PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2394378085