From jkratochvil at openjdk.org  Wed Oct  1 08:36:09 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Oct 2025 08:36:09 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <2lhgNVxcVrPn_s7qpT174bl3FXTKuOj59ZScMGJHf5g=.d18ae148-a6ac-4a44-8a02-e2d82a5f2091@github.com>

On Tue, 30 Sep 2025 13:17:54 GMT, Radim Vansa <rvansa 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/java.base/share/native/libcrexec/image_constraints.cpp line 155:

> 153:     assert(eq < nl);
> 154:     if (!strncmp(line, LABEL_PREFIX, strlen(LABEL_PREFIX))) {
> 155:       Tag& t = tags.add({

/home/runner/work/crac/crac/src/java.base/share/native/libcrexec/image_constraints.cpp:155:12: error: unused variable ?t? [-Werror=unused-variable]

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

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

From tpushkin at openjdk.org  Wed Oct  1 08:50:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 1 Oct 2025 08:50:11 GMT
Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5]
In-Reply-To: <oIJQGc5WEr0QnPu-dA_YfMmPUsH145QnYzLMI1Jh_cQ=.9455604b-cf3a-48b4-b361-fa2658f3f5ad@github.com>
References: <L_QFlrzV7LV0_J1PS3yANUKD29Pwe61udihgWftu37I=.d65ac7db-e185-4db7-97b3-6fdcd36584a8@github.com>
 <oIJQGc5WEr0QnPu-dA_YfMmPUsH145QnYzLMI1Jh_cQ=.9455604b-cf3a-48b4-b361-fa2658f3f5ad@github.com>
Message-ID: <WkZDnPLQVYoUo7_NV2w-Cy6bBy1a6sPN7zD1EqhOlx8=.51cae84c-99b4-46e0-8785-6fd994b95ecf@github.com>

On Mon, 29 Sep 2025 13:57:16 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible.
>> 
>> Also improved reading from output stream.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comment

@wkia I am waiting for your acknowledgment of the above before sponsoring

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

PR Comment: https://git.openjdk.org/crac/pull/265#issuecomment-3355352024

From jkratochvil at openjdk.org  Wed Oct  1 08:53:08 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Oct 2025 08:53:08 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>

On Tue, 30 Sep 2025 13:17:54 GMT, Radim Vansa <rvansa 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?

src/hotspot/share/runtime/crac.cpp line 527:

> 525:   // Since the check itself is delegated to the C/R Engine we will simply
> 526:   // skip the check here (or prevent storing the features in the image).
> 527: #ifdef __x86_64__

One should not use `#ifdef` as it may lead to compilation errors on other arches.

src/hotspot/share/runtime/crac.cpp line 589:

> 587:   if (ret == RESTORE_ERROR_INVALID) {
> 588:     log_error(crac)("CRaC engine failed to restore from %s: the image is either corrupted or does not match current CPU", CRaCRestoreFrom);
> 589: #ifdef __x86_64__

Likewise one should not use `#ifdef` as it may lead to compilation errors on other arches.

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

> 37: 
> 38: static FILE *open_tags(const char *image_location, const char *mode) {
> 39:    char fname[PATH_MAX];

whitespace

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

> 59:         fprintf(f, LABEL_PREFIX "%s=%s\n", tag.name, static_cast<const char *>(tag.data));
> 60:     } else {
> 61:         fprintf(f, BITMAP_PREFIX "%s=", tag.name);

indentation 2 vs. 4

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

> 75: 
> 76: static inline unsigned char from_hex(char c, bool *err) {
> 77:     if (c >= '0' && c <= '9') {

again changed indentation, more occurences in this file

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

PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393876679
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393871031
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393871594
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393878601
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393881789
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2393884186

From jkratochvil at openjdk.org  Wed Oct  1 09:23:11 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Oct 2025 09:23:11 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <XWe9DXOaZmud5PJFzrL_V9UlNOjqGYACoC8oSQQSD2U=.fbbb0440-a52d-487a-aaa0-e515c7221315@github.com>

On Tue, 30 Sep 2025 13:17:54 GMT, Radim Vansa <rvansa 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/java.base/share/native/libcrexec/image_constraints.cpp line 198:

> 196:   });
> 197:   Hashtable<Tag> ht(keys, tags.size());
> 198:   delete keys;

src/java.base/share/native/libcrexec/image_constraints.cpp:198:3: warning: 'delete' applied to a pointer that was allocated with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete]
  198 |   delete keys;
      |   ^
      |         []
src/java.base/share/native/libcrexec/image_constraints.cpp:188:23: note: allocated with 'new[]' here
  188 |   const char **keys = new(std::nothrow) const char*[tags.size()];
      |                       ^

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

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

From rvansa at openjdk.org  Wed Oct  1 12:22:44 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 1 Oct 2025 12:22:44 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
Message-ID: <Ja07v2h5Kh1YV8eTY1A69KGfH6-lChbEbp01Pb0dLVg=.152518fc-6265-4c2a-ad76-5b1f79b52689@github.com>

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

From rvansa at openjdk.org  Wed Oct  1 12:24:53 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 1 Oct 2025 12:24:53 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
Message-ID: <j88vOJyLLeHrV_IaHnM-e7TAQhTufqfVXRr8HlobI3w=.4362d97d-1674-484f-94ac-ff931d7c247b@github.com>

On Wed, 1 Oct 2025 08:45:57 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/runtime/crac.cpp line 527:
> 
>> 525:   // Since the check itself is delegated to the C/R Engine we will simply
>> 526:   // skip the check here (or prevent storing the features in the image).
>> 527: #ifdef __x86_64__
> 
> One should not use `#ifdef` as it may lead to compilation errors on other arches.

How is this different from creating an arch-specific method with different implementations? To me that look just like a boilerplate (and the presence is only checked for currently compiled arch - so I won't make sure that the code work on all archs).

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

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

From jkratochvil at openjdk.org  Wed Oct  1 12:53:18 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Oct 2025 12:53:18 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <j88vOJyLLeHrV_IaHnM-e7TAQhTufqfVXRr8HlobI3w=.4362d97d-1674-484f-94ac-ff931d7c247b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
 <j88vOJyLLeHrV_IaHnM-e7TAQhTufqfVXRr8HlobI3w=.4362d97d-1674-484f-94ac-ff931d7c247b@github.com>
Message-ID: <siGkdd2BQ-sep6mHhGNaHtffD04j-CxA6XQaCWOvsdk=.5caa52cf-c614-4bb0-bbee-6e5654195907@github.com>

On Wed, 1 Oct 2025 12:22:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac.cpp line 527:
>> 
>>> 525:   // Since the check itself is delegated to the C/R Engine we will simply
>>> 526:   // skip the check here (or prevent storing the features in the image).
>>> 527: #ifdef __x86_64__
>> 
>> One should not use `#ifdef` as it may lead to compilation errors on other arches.
>
> How is this different from creating an arch-specific method with different implementations? To me that look just like a boilerplate (and the presence is only checked for currently compiled arch - so I won't make sure that the code work on all archs).

It is true there are no target-specific files/classes. But there still can be:

class crac {
static bool is_x86_64() {
#ifdef __x86_64__
  return true;
#else
  return false;
#endif
  };
};
if (is_x86_64()) {
  ...
}

Then all arch-specific code is compile-time checked on all arches.

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

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

From rmarchenko at openjdk.org  Thu Oct  2 07:10:26 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 2 Oct 2025 07:10:26 GMT
Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5]
In-Reply-To: <oIJQGc5WEr0QnPu-dA_YfMmPUsH145QnYzLMI1Jh_cQ=.9455604b-cf3a-48b4-b361-fa2658f3f5ad@github.com>
References: <L_QFlrzV7LV0_J1PS3yANUKD29Pwe61udihgWftu37I=.d65ac7db-e185-4db7-97b3-6fdcd36584a8@github.com>
 <oIJQGc5WEr0QnPu-dA_YfMmPUsH145QnYzLMI1Jh_cQ=.9455604b-cf3a-48b4-b361-fa2658f3f5ad@github.com>
Message-ID: <er6No1vpGdk5buYj0YcLsAGMZzPIArFaeEMM-DxQGao=.ffb0181f-e30c-49d9-b35f-e73578a9ba55@github.com>

On Mon, 29 Sep 2025 13:57:16 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible.
>> 
>> Also improved reading from output stream.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comment

Files as JDK-8369035

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

PR Comment: https://git.openjdk.org/crac/pull/265#issuecomment-3359494744

From rmarchenko at openjdk.org  Thu Oct  2 09:23:33 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 2 Oct 2025 09:23:33 GMT
Subject: [crac] Integrated: 8368570: [CRaC] Improve JdwpTransportTest
In-Reply-To: <L_QFlrzV7LV0_J1PS3yANUKD29Pwe61udihgWftu37I=.d65ac7db-e185-4db7-97b3-6fdcd36584a8@github.com>
References: <L_QFlrzV7LV0_J1PS3yANUKD29Pwe61udihgWftu37I=.d65ac7db-e185-4db7-97b3-6fdcd36584a8@github.com>
Message-ID: <n8zLn6wKemta9J7EJTEQEy72Pq5j-RveAFL_nEBAgps=.03d1198c-f466-41ef-b8ab-e167ea3efd3b@github.com>

On Wed, 24 Sep 2025 15:18:35 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible.
> 
> Also improved reading from output stream.

This pull request has now been integrated.

Changeset: 5abb5dac
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/5abb5dac8e9785ad0c38e238e526775f98617aec
Stats:     181 lines in 3 files changed: 167 ins; 5 del; 9 mod

8368570: [CRaC] Improve JdwpTransportTest

Reviewed-by: tpushkin

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

PR: https://git.openjdk.org/crac/pull/265

From tpushkin at openjdk.org  Thu Oct  2 09:40:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 2 Oct 2025 09:40:54 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v4]
In-Reply-To: <lxE-9JWhnLbOJ0X4payNYtxmAyKO61tsB8Rrf5qiV5o=.bd396c96-aef6-4600-a2d5-6d6cdd794ee9@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
 <BA1RIpr8j3RC6AAyez9aJ_i3EvJWT3-ChATThy6LlLU=.7116ab01-5375-467d-b755-bf56bd7e3b69@github.com>
 <lxE-9JWhnLbOJ0X4payNYtxmAyKO61tsB8Rrf5qiV5o=.bd396c96-aef6-4600-a2d5-6d6cdd794ee9@github.com>
Message-ID: <c38rYGy7MH--Gm_Uxi2yZRBFh7yIrSRLH9wPXOWLZlo=.88e8ab6d-afc8-42be-96a7-3b66e4356ea7@github.com>

On Tue, 30 Sep 2025 13:01:08 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Notice about empty %f
>
> Looks like when I've created the PR from a branch in this repository the GHA with tests is not executed. Pushed the code to my repo, too, tests running here: https://github.com/rvansa/crac/actions/runs/18130706409

@rvansa There are still build and test failures in your repo

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

PR Comment: https://git.openjdk.org/crac/pull/264#issuecomment-3360163864

From rvansa at openjdk.org  Thu Oct  2 10:12:28 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 2 Oct 2025 10:12:28 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
In-Reply-To: <siGkdd2BQ-sep6mHhGNaHtffD04j-CxA6XQaCWOvsdk=.5caa52cf-c614-4bb0-bbee-6e5654195907@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
 <j88vOJyLLeHrV_IaHnM-e7TAQhTufqfVXRr8HlobI3w=.4362d97d-1674-484f-94ac-ff931d7c247b@github.com>
 <siGkdd2BQ-sep6mHhGNaHtffD04j-CxA6XQaCWOvsdk=.5caa52cf-c614-4bb0-bbee-6e5654195907@github.com>
Message-ID: <fagU6jGa2q5-ews4M0QagOAVBFXBGTBPAf_Gx07lqyc=.f64ebb37-1dce-4071-bce1-54511879c56f@github.com>

On Wed, 1 Oct 2025 12:50:20 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> How is this different from creating an arch-specific method with different implementations? To me that look just like a boilerplate (and the presence is only checked for currently compiled arch - so I won't make sure that the code work on all archs).
>
> It is true there are no target-specific files/classes. But there still can be:
> 
> class crac {
> static bool is_x86_64() {
> #ifdef __x86_64__
>   return true;
> #else
>   return false;
> #endif
>   };
> };
> if (is_x86_64()) {
>   ...
> }
> 
> Then all arch-specific code is compile-time checked on all arches.

The ifdef in here is doing exactly that - guarding a VM option that is defined only on x86_64... though it looks like the CI is compiling against the 'zero' architecture (which lacks the VM option despite the macro is defined).

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

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

From tpushkin at openjdk.org  Thu Oct  2 12:03:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 2 Oct 2025 12:03:32 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v2]
In-Reply-To: <E7bFOP_dUiv5yBLSpfUt93VILk66jHRPYQ2xKVkRMRg=.1f1d3a24-8eca-4516-87f2-b5940959cfaf@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
 <E7bFOP_dUiv5yBLSpfUt93VILk66jHRPYQ2xKVkRMRg=.1f1d3a24-8eca-4516-87f2-b5940959cfaf@github.com>
Message-ID: <-ExhrVfQmNpShsXMZjwQ820uwMSTTTnEN3-RWK68Tds=.3e0af41a-d846-4363-9fc6-f7da48b631ad@github.com>

On Tue, 30 Sep 2025 08:58:33 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Add support for pattern in `CRaCCheckpointTo` VM option.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/hotspot/share/runtime/crac.cpp line 155:

> 153:     } else if ((size_t) ret > buflen) { \
> 154:       log_error(crac)("Error interpolating CRaCCheckpointTo=%s", CRaCCheckpointTo); \
> 155:       return false; \

Shouldn't the error messages be swapped? For snprintf, if `ret > buflen` then the buffer was too small, if `ret < 0` then it is some encoding error. Also I think it should be `ret >= buflen` since `ret` does not count the nul terminator.

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

PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398065792

From tpushkin at openjdk.org  Thu Oct  2 12:03:33 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 2 Oct 2025 12:03:33 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v5]
In-Reply-To: <A6IfPETmZL9qOkuZGrk4xX63CkXxpqbqEtkkDiz6A30=.1fa998bd-0a12-4475-9750-f6573794ea5d@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
 <A6IfPETmZL9qOkuZGrk4xX63CkXxpqbqEtkkDiz6A30=.1fa998bd-0a12-4475-9750-f6573794ea5d@github.com>
Message-ID: <sOsuS9-2QprVTF2Cwg6lQpSAIJuUOyLExe3eTtVqwoU=.6f4cc5e8-a2fd-4e57-905b-b8f14ed1778f@github.com>

On Tue, 30 Sep 2025 13:39:59 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Add support for pattern in `CRaCCheckpointTo` VM option.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

src/hotspot/share/runtime/crac.cpp line 221:

> 219:           int ret = data.print_numbers(buf, buflen, true);
> 220:           buf += ret;
> 221:           buflen -= ret;

We only check that there is enough space for a single character in the buffer while `print_numbers` asserts that there is enough space for all the features to fit. I.e. I believe it is possible to go past the end of the buffer here.

Although not a part of this change, but the assert in `print_numbers` should be before subtracting from `buflen`, not after.

src/hotspot/share/runtime/crac.cpp line 301:

> 299:   // Note that CRaCEngine and CRaCEngineOptions are not updated (as documented)
> 300:   // so we don't need to re-init the whole engine handle.
> 301:     char image_location[PATH_MAX];

Suggestion:

  char image_location[PATH_MAX];

src/hotspot/share/runtime/globals.hpp line 1965:

> 1963:           "image is a directory, the directory will be created if it does " \
> 1964:           "not exist (parent directories are not created) or overwritten "  \
> 1965:           "otherwise. The path can contain placeholders (e.g. %p for PID);" \

Whitespace is missing after ";"

src/java.base/share/man/java.md line 1088:

> 1086:     these placeholders:
> 1087:     -   `%%`: single % character
> 1088:     -   `%a`: architecture (x86_64 or aarch64)

Are you sure it is always one of these? [This code](https://github.com/openjdk/crac/blob/5abb5dac8e9785ad0c38e238e526775f98617aec/make/autoconf/platform.m4#L475) suggests that it can be i386 or amd64 for example. Also the shared part of CRaC is probably compilable for other arches too. Maybe better to say it is the same as what `os.arch` returns?

src/java.base/share/man/java.md line 1095:

> 1093:               separators) with second precision, e.g. `20250909T141711Z`
> 1094:     -   `%T`: checkpoint epoch time (second precision)
> 1095:     -   `%b` and `%B`: process boot time (generation 1), same format as `%t` or `%T`

I suggest putting the description of `%g` before this (between `%u` and `%t`, for example) so that the definition of a "generation" is more clear when the reader reaches this point

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

PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398115959
PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398519612
PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398533814
PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398429069
PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2398460145

From rvansa at openjdk.org  Thu Oct  2 14:06:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 2 Oct 2025 14:06:59 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v2]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <SBVrjS8bJGvgYbgBOgy-cFWizk-rD4653c1UePesu7c=.62c6961b-1a0a-4e30-ae72-1ff56d609966@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Remove ifdefs, fix indentation

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/638f917e..23fa684d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=01
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=00-01

  Stats: 75 lines in 9 files changed: 19 ins; 16 del; 40 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From jkratochvil at openjdk.org  Thu Oct  2 14:07:01 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 2 Oct 2025 14:07:01 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v2]
In-Reply-To: <fagU6jGa2q5-ews4M0QagOAVBFXBGTBPAf_Gx07lqyc=.f64ebb37-1dce-4071-bce1-54511879c56f@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <020ZiSSBydDui_QrTAcBrUdOqISSYGqDw5OvkE2VASM=.761d251f-4ba7-409c-85a0-3964a4087900@github.com>
 <j88vOJyLLeHrV_IaHnM-e7TAQhTufqfVXRr8HlobI3w=.4362d97d-1674-484f-94ac-ff931d7c247b@github.com>
 <siGkdd2BQ-sep6mHhGNaHtffD04j-CxA6XQaCWOvsdk=.5caa52cf-c614-4bb0-bbee-6e5654195907@github.com>
 <fagU6jGa2q5-ews4M0QagOAVBFXBGTBPAf_Gx07lqyc=.f64ebb37-1dce-4071-bce1-54511879c56f@github.com>
Message-ID: <c3U9pYKJU-gKSOWFfr9Sg8pFqVBkeaJFfHYhUZsnM64=.985e9d14-fb24-40cd-accd-00b3f8bfc2d0@github.com>

On Thu, 2 Oct 2025 10:09:39 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> It is true there are no target-specific files/classes. But there still can be:
>> 
>> class crac {
>> static bool is_x86_64() {
>> #ifdef __x86_64__
>>   return true;
>> #else
>>   return false;
>> #endif
>>   };
>> };
>> if (is_x86_64()) {
>>   ...
>> }
>> 
>> Then all arch-specific code is compile-time checked on all arches.
>
> The ifdef in here is doing exactly that - guarding a VM option that is defined only on x86_64... though it looks like the CI is compiling against the 'zero' architecture (which lacks the VM option despite the macro is defined).

I do not mind how it is done, I was trying to suggest more compile-time checks. If you disagree then let's just close this thread.

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

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

From rvansa at openjdk.org  Thu Oct  2 14:29:24 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 2 Oct 2025 14:29:24 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v3]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <L5WL9SkVyBaRS7EQPo8sQsuLhdx3OpNJtKcKRH-RmdU=.1c9615d7-7f70-475f-b5be-c2adbe265604@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Add constexpr

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/23fa684d..85e733c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=02
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=01-02

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Thu Oct  2 19:22:10 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 2 Oct 2025 19:22:10 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Fix NoCPUFeaturesTest

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/85e733c1..a2f2b3c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=03
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=02-03

  Stats: 25 lines in 2 files changed: 21 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From tpushkin at openjdk.org  Fri Oct  3 12:02:30 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 3 Oct 2025 12:02:30 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
Message-ID: <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>

On Thu, 2 Oct 2025 19:22:10 GMT, Radim Vansa <rvansa 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).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NoCPUFeaturesTest

Regarding `crexec` changes, I wonder if it would be easier for us to use the C++ stdlib fully (`std::vector`, `std::unordered_map`) catching all exceptions...

src/hotspot/cpu/x86/vm_version_x86.hpp line 617:

> 615:     static constexpr size_t print_buffer_length() {
> 616:       return MAX_CPU_FEATURES;
> 617:     }

I believe by the time the corresponding printing function is used the resource area is already initialized. It thus should be possible to make it allocate a resource array internally instead of making the callers use this to allocate on stack. Or there can be two functions: one that uses a provided buffer and its wrapper that allocates a resource array.

src/java.base/share/native/libcrexec/crexec.cpp line 142:

> 140:   &restore_data_extension.header,
> 141:   &user_data_extension.header,
> 142:   &image_constraints_extension.header,

Since we replace the direct use of user data with this new extension it should be a bit more efficient to put the new extension above the old one

src/java.base/share/native/libcrexec/crexec.cpp line 837:

> 835:   if (error) {
> 836:     return error;
> 837:   }

Nitpick: let's move this before initializing `restore_data_str` as this is a part of argument validation while `restore_data_str` and below is preparation for exec-ing

src/java.base/share/native/libcrexec/hashtable.hpp line 143:

> 141:   *value_ptr = std::forward<T>(value);
> 142:   return true;
> 143: }

I believe this usage of `std::forward` is incorrect as `T` is deduced from the hashtable class and not from the `value` parameter, so with this change it is now not possible to pass lvalues as `value`. I think the best would be to leave `T value` as it was and replace `std::forward` with `std::move` ? lvalues will be copied then moved, rvalues will be just moved.

Same for `LinkedList::add`.

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

> 37: 
> 38: static FILE *open_tags(const char *image_location, const char *mode) {
> 39:   char fname[PATH_MAX];

In `crexec.cpp` we for some reason have our own conditional definition of `PATH_MAX`, I guess it caused problems at some point... Maybe create some `common.hpp` or `crexec.hpp` where `PATH_MAX` and `CREXEC` would be defined?

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

> 44:   FILE *f = fopen(fname, mode);
> 45:   if (f == nullptr) {
> 46:     fprintf(stderr, CREXEC "cannot open(%s) %s: %s\n", fname, mode, strerror(errno));

Suggestion:

    fprintf(stderr, CREXEC "cannot open %s in %s mode: %s\n", fname, mode, strerror(errno));

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

> 140:     return errno == ENOENT ? RESTORE_ERROR_NOT_FOUND : RESTORE_ERROR_NO_ACCESS;
> 141:   }
> 142:   char line[strlen(BITMAP_PREFIX) + _max_name_length + 1 + _max_value_length + 2];

AFAIR MSVC does not support arrays of non-constexpr size

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

> 144:   while (fgets(line, sizeof(line), f)) {
> 145:     char *eq = strchr(line, '=');
> 146:     char *nl = strchr(eq + 1, '\n');

I believe parsing will be broken if `=` is encountered in the tag name itself. Same for `\n` although that is less likely.

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

> 158:         .data = strdup(eq + 1),
> 159:         .data_length = (size_t) (nl - eq),
> 160:       });

Missing error checking here and below (`add`, `strdup`, `malloc`)

src/java.base/share/native/libcrexec/image_constraints.hpp line 36:

> 34: class ImageConstraints {
> 35: private:
> 36:   enum TagType {

It can have a smaller base type, and also making it a class is more idiomatic I believe
Suggestion:

  enum class TagType : std::uint8_t {

src/java.base/share/native/libcrexec/image_constraints.hpp line 93:

> 91: 
> 92:   const size_t _max_name_length = 256;
> 93:   const size_t _max_value_length = 256;

Suggestion:

  static constexpr size_t _MAX_NAME_LENGTH = 256;
  static constexpr size_t _MAX_VALUE_LENGTH = 256;

src/java.base/share/native/libcrexec/image_constraints.hpp line 95:

> 93:   const size_t _max_value_length = 256;
> 94: 
> 95:   bool check_tag(const char *name) {

"check" has too broad meaning IMO
Suggestion:

  bool has_tag(const char *name) const {

src/java.base/share/native/libcrexec/image_constraints.hpp line 119:

> 117:       .data = strdup(value),
> 118:       .data_length = value_length,
> 119:     });

`add` and `strdup`s can fail ? this should be checked

src/java.base/share/native/libcrexec/linkedlist.hpp line 42:

> 40:   size_t _size;
> 41: public:
> 42:   LinkedList(): _head(nullptr), _tail(nullptr), _size(0) {}

Suggestion:

  Node *_head = nullptr;
  Node *_tail = nullptr;
  size_t _size = 0;
public:

src/java.base/share/native/libcrexec/linkedlist.hpp line 52:

> 50:   }
> 51: 
> 52:   T& add(T&& item) {

With the current style this should be:
Suggestion:

  T &add(T &&item) {

src/java.base/share/native/libcrexec/linkedlist.hpp line 53:

> 51: 
> 52:   T& add(T&& item) {
> 53:     Node *node = new(std::nothrow) Node();

Should do a null check after this

src/java.base/share/native/libcrexec/linkedlist.hpp line 74:

> 72:       node = node->_next;
> 73:     }
> 74:   }

I don't insist but implementing an `std::iterator` does not seem too cumbersome and would allow to use the normal for loop

src/java.base/share/native/libcrexec/linkedlist.hpp line 76:

> 74:   }
> 75: 
> 76:   size_t size() {

Suggestion:

  size_t size() const {

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

PR Review: https://git.openjdk.org/crac/pull/266#pullrequestreview-3298008166
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401210494
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401621379
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401643142
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401437652
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401543883
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401555404
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401594497
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401576791
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401598125
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401495490
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401506384
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401501558
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401523886
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401237419
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401444477
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401231987
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401266298
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401258129

From tpushkin at openjdk.org  Fri Oct  3 12:02:30 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 3 Oct 2025 12:02:30 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
Message-ID: <TtlhdG29N26Zn7WMQLUBqk7vGY_dNAM498Bc_boujCk=.51fcbaba-0a64-4fbb-af78-283a15de0f6a@github.com>

On Fri, 3 Oct 2025 11:05:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NoCPUFeaturesTest
>
> src/java.base/share/native/libcrexec/image_constraints.cpp line 39:
> 
>> 37: 
>> 38: static FILE *open_tags(const char *image_location, const char *mode) {
>> 39:   char fname[PATH_MAX];
> 
> In `crexec.cpp` we for some reason have our own conditional definition of `PATH_MAX`, I guess it caused problems at some point... Maybe create some `common.hpp` or `crexec.hpp` where `PATH_MAX` and `CREXEC` would be defined?

Yep, probably this is the reason: https://github.com/rvansa/crac/actions/runs/18203262060/job/51827234536#step:10:8170

> src/java.base/share/native/libcrexec/image_constraints.hpp line 93:
> 
>> 91: 
>> 92:   const size_t _max_name_length = 256;
>> 93:   const size_t _max_value_length = 256;
> 
> Suggestion:
> 
>   static constexpr size_t _MAX_NAME_LENGTH = 256;
>   static constexpr size_t _MAX_VALUE_LENGTH = 256;

A nitpick, but in the case of labels, where both names and values are strings it may be error-prone that the first refers to a length excluding the nul-char and the second refers to the full size including the nul-char. I usually use "length" for the first and "size" for the second.

> src/java.base/share/native/libcrexec/image_constraints.hpp line 119:
> 
>> 117:       .data = strdup(value),
>> 118:       .data_length = value_length,
>> 119:     });
> 
> `add` and `strdup`s can fail ? this should be checked

Error-checking in the functions below is also lacking

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

PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401591494
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401517189
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2401525482

From rvansa at openjdk.org  Mon Oct  6 07:14:24 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 6 Oct 2025 07:14:24 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v5]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <-kg2EsaHUvElvN3SVbkDNEic16GIUfLBpBvY64-aEVs=.5682e209-3e58-4d4a-9de7-52ed8a49f5f3@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Reset conf before 2nd checkpoint

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/a2f2b3c7..650b6798

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=04
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=03-04

  Stats: 120 lines in 6 files changed: 79 ins; 35 del; 6 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Mon Oct  6 08:15:43 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 6 Oct 2025 08:15:43 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v6]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <i1JruQOe3FITMFbNsHorqyNf5NuqknkVWhJBIO_SSrk=.0c0bd74c-b8f2-44e4-b660-722753b9fca1@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Fix windows build

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/650b6798..e0e399f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=05
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=04-05

  Stats: 46 lines in 2 files changed: 8 ins; 22 del; 16 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Mon Oct  6 15:27:06 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 6 Oct 2025 15:27:06 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
Message-ID: <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>

On Fri, 3 Oct 2025 10:07:58 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NoCPUFeaturesTest
>
> src/java.base/share/native/libcrexec/hashtable.hpp line 143:
> 
>> 141:   *value_ptr = std::forward<T>(value);
>> 142:   return true;
>> 143: }
> 
> I believe this usage of `std::forward` is incorrect as `T` is deduced from the hashtable class and not from the `value` parameter, so with this change it is now not possible to pass lvalues as `value`. I think the best would be to leave `T value` as it was and replace `std::forward` with `std::move` ? lvalues will be copied then moved, rvalues will be just moved.
> 
> Same for `LinkedList::add`.

This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).
Sources:
* https://blog.vero.site/post/rvalue-references 
* https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

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

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

From tpushkin at openjdk.org  Mon Oct  6 18:57:28 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 6 Oct 2025 18:57:28 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
Message-ID: <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>

On Mon, 6 Oct 2025 15:24:28 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/native/libcrexec/hashtable.hpp line 143:
>> 
>>> 141:   *value_ptr = std::forward<T>(value);
>>> 142:   return true;
>>> 143: }
>> 
>> I believe this usage of `std::forward` is incorrect as `T` is deduced from the hashtable class and not from the `value` parameter, so with this change it is now not possible to pass lvalues as `value`. I think the best would be to leave `T value` as it was and replace `std::forward` with `std::move` ? lvalues will be copied then moved, rvalues will be just moved.
>> 
>> Same for `LinkedList::add`.
>
> This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).
> Sources:
> * https://blog.vero.site/post/rvalue-references 
> * https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

I understand what was the intention here, and thanks for the links. But I believe in this case `value` is not a universal reference because `T` gets deduced from the `Hashtable<T>` object, not from the `value` parameter.

Looks like this is discussed in your second link:
> Sometimes you can see `T&&` in a function template declaration where `T` is a template parameter, yet there?s still no type deduction.  Consider this `push_back` function in `std::vector`:
> 
> ```
> template <class T, class Allocator = allocator<T> >
> class vector {
> public:
>     ...
>     void push_back(T&& x);       // fully specified parameter type ? no type deduction;
>     ...                          // && ? rvalue reference
> };
> ```
> Here, `T` is a template parameter, and `push_back` takes a `T&&`, yet the parameter is not a universal reference!  How can that be?
> 
> The answer becomes apparent if we look at how `push_back` would be declared outside the class. I?m going to pretend that `std::vector`?s `Allocator` parameter doesn?t exist, because it?s irrelevant to the discussion, and it just clutters up the code.  With that in mind, here?s the declaration for this version of `std::vector::push_back`:
> 
> ```
> template <class T>
> void vector<T>::push_back(T&& x);
> ```
> `push_back` can?t exist without the class `std::vector<T>` that contains it.  But if we have a class `std::vector<T>`, we already know what `T` is, so there?s no need to deduce it.
> 
> An example will help.  If I write
> 
> ```
> Widget makeWidget();             // factory function for Widget
> std::vector<Widget> vw;
> ...
> Widget w;
> vw.push_back(makeWidget());      // create Widget from factory, add it to vw
> ```
> my use of `push_back` will cause the compiler to instantiate that function for the class `std::vector<Widget>`. The declaration for that `push_back` looks like this:
> ```
> void std::vector<Widget>::push_back(Widget&& x);
> ```
> See?  Once we know that the class is `std::vector<Widget>`, the type of `push_back`?s parameter is fully determined:  it?s `Widget&&`.  There?s no role here for type deduction.

I think something like [this](https://stackoverflow.com/a/70435367/16360266) is needed to make it a universal reference.

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

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

From tpushkin at openjdk.org  Mon Oct  6 19:21:33 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 6 Oct 2025 19:21:33 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
 <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
Message-ID: <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>

On Mon, 6 Oct 2025 18:54:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).
>> Sources:
>> * https://blog.vero.site/post/rvalue-references 
>> * https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers
>
> I understand what was the intention here, and thanks for the links. But I believe in this case `value` is not a universal reference because `T` gets deduced from the `Hashtable<T>` object, not from the `value` parameter.
> 
> Looks like this is discussed in your second link:
>> Sometimes you can see `T&&` in a function template declaration where `T` is a template parameter, yet there?s still no type deduction.  Consider this `push_back` function in `std::vector`:
>> 
>> ```
>> template <class T, class Allocator = allocator<T> >
>> class vector {
>> public:
>>     ...
>>     void push_back(T&& x);       // fully specified parameter type ? no type deduction;
>>     ...                          // && ? rvalue reference
>> };
>> ```
>> Here, `T` is a template parameter, and `push_back` takes a `T&&`, yet the parameter is not a universal reference!  How can that be?
>> 
>> The answer becomes apparent if we look at how `push_back` would be declared outside the class. I?m going to pretend that `std::vector`?s `Allocator` parameter doesn?t exist, because it?s irrelevant to the discussion, and it just clutters up the code.  With that in mind, here?s the declaration for this version of `std::vector::push_back`:
>> 
>> ```
>> template <class T>
>> void vector<T>::push_back(T&& x);
>> ```
>> `push_back` can?t exist without the class `std::vector<T>` that contains it.  But if we have a class `std::vector<T>`, we already know what `T` is, so there?s no need to deduce it.
>> 
>> An example will help.  If I write
>> 
>> ```
>> Widget makeWidget();             // factory function for Widget
>> std::vector<Widget> vw;
>> ...
>> Widget w;
>> vw.push_back(makeWidget());      // create Widget from factory, add it to vw
>> ```
>> my use of `push_back` will cause the compiler to instantiate that function for the class `std::vector<Widget>`. The declaration for that `push_back` looks like this:
>> ```
>> void std::vector<Widget>::push_back(Widget&& x);
>> ```
>> See?  Once we know that the class is `std::vector<Widget>`, the type of `push_back`?s parameter is fully determined:  it?s `Widget&&`.  There?s no role here for type deduction.
> 
> I think something like [this](https://stackoverflow.com/a/70435367/16360266) is needed to make it a universal reference.

> for std::move I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).

To clarify, my suggestion was to leave the parameter as `T value` so that we can safely use `std::move` to treat it as an rvalue reference and move from it. An lvalue argument will be copied into `value` and then the copy will be moved into `*value_ptr`. An rvalue argument will be moved into `value` and then moved into `*value_ptr` --- probably the compiler optimizes these moves but I haven't researched this enough.

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

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

From jkratochvil at openjdk.org  Tue Oct  7 10:49:44 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 7 Oct 2025 10:49:44 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
 <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
 <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>
Message-ID: <7roBfqhr2JZOllt4aL9WWofFJaPxXRvmFTGncmJ60M4=.6f06354b-5611-41f4-8ad1-8fd9984d61e6@github.com>

On Mon, 6 Oct 2025 19:18:19 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> I understand what was the intention here, and thanks for the links. But I believe in this case `value` is not a universal reference because `T` gets deduced from the `Hashtable<T>` object, not from the `value` parameter.
>> 
>> Looks like this is discussed in your second link:
>>> Sometimes you can see `T&&` in a function template declaration where `T` is a template parameter, yet there?s still no type deduction.  Consider this `push_back` function in `std::vector`:
>>> 
>>> ```
>>> template <class T, class Allocator = allocator<T> >
>>> class vector {
>>> public:
>>>     ...
>>>     void push_back(T&& x);       // fully specified parameter type ? no type deduction;
>>>     ...                          // && ? rvalue reference
>>> };
>>> ```
>>> Here, `T` is a template parameter, and `push_back` takes a `T&&`, yet the parameter is not a universal reference!  How can that be?
>>> 
>>> The answer becomes apparent if we look at how `push_back` would be declared outside the class. I?m going to pretend that `std::vector`?s `Allocator` parameter doesn?t exist, because it?s irrelevant to the discussion, and it just clutters up the code.  With that in mind, here?s the declaration for this version of `std::vector::push_back`:
>>> 
>>> ```
>>> template <class T>
>>> void vector<T>::push_back(T&& x);
>>> ```
>>> `push_back` can?t exist without the class `std::vector<T>` that contains it.  But if we have a class `std::vector<T>`, we already know what `T` is, so there?s no need to deduce it.
>>> 
>>> An example will help.  If I write
>>> 
>>> ```
>>> Widget makeWidget();             // factory function for Widget
>>> std::vector<Widget> vw;
>>> ...
>>> Widget w;
>>> vw.push_back(makeWidget());      // create Widget from factory, add it to vw
>>> ```
>>> my use of `push_back` will cause the compiler to instantiate that function for the class `std::vector<Widget>`. The declaration for that `push_back` looks like this:
>>> ```
>>> void std::vector<Widget>::push_back(Widget&& x);
>>> ```
>>> See?  Once we know that the class is `std::vector<Widget>`, the type of `push_back`?s parameter is fully determined:  it?s `Widget&&`.  There?s no role here for type deduction.
>> 
>> I think something like [this](https://stackoverflow.com/a/70435367/16360266) is needed to make it a universal reference.
>
>> for std::move I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).
> 
> To clarify, my suggestion was to leave the parameter as `T value` so that we can safely use `std::move` to treat it as an rvalue reference and move from it. An lvalue argument will be copied into `value` and then the copy will be moved into `*value_ptr`. An rvalue argument will be moved into `value` and then moved into `*value_ptr` --- probably the compiler optimizes these moves but I haven't researched this enough.

> This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value). Sources:

One can try it does not compile:

#include "hashtable.hpp"
int main() {
  Hashtable<int> h(nullptr, 10);
  int i = 42;
  h.put("foo", i);
}
h.cpp:5:16: error: rvalue reference to type 'int' cannot bind to lvalue of type 'int'
    5 |   h.put("foo", i);
      |                ^
src/java.base/share/native/libcrexec/hashtable.hpp:47:33: note: passing argument to parameter 'value' here
   47 |   bool put(const char *key, T&& value);
      |                                 ^
1 error generated.

Couldn't we use a new template parameter for the method?
[tu.patch](https://github.com/user-attachments/files/22741639/tu.patch)

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

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

From rvansa at openjdk.org  Tue Oct  7 12:03:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:03:55 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v7]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <Jgljamknx2r90KSrWnbOAe7eSrisWjwIsrYWRRhFipw=.0eae009e-73b9-4ebf-b95e-e88f8dd0c1af@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Fixup
 - Review update

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/e0e399f7..55c50f21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=06
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=05-06

  Stats: 418 lines in 21 files changed: 163 ins; 95 del; 160 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Tue Oct  7 12:03:57 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:03:57 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <7roBfqhr2JZOllt4aL9WWofFJaPxXRvmFTGncmJ60M4=.6f06354b-5611-41f4-8ad1-8fd9984d61e6@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
 <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
 <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>
 <7roBfqhr2JZOllt4aL9WWofFJaPxXRvmFTGncmJ60M4=.6f06354b-5611-41f4-8ad1-8fd9984d61e6@github.com>
Message-ID: <Ib1vM3SxnOaYx-e9Lk_0Nuk4RSf1t439LjE28a8fSm4=.60772cab-44bc-41af-876b-4de683fd3756@github.com>

On Tue, 7 Oct 2025 10:46:52 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>>> for std::move I would have to pass rvalue reference (therefore the method wouldn't be usable with const value).
>> 
>> To clarify, my suggestion was to leave the parameter as `T value` so that we can safely use `std::move` to treat it as an rvalue reference and move from it. An lvalue argument will be copied into `value` and then the copy will be moved into `*value_ptr`. An rvalue argument will be moved into `value` and then moved into `*value_ptr` --- probably the compiler optimizes these moves but I haven't researched this enough.
>
>> This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value). Sources:
> 
> One can try it does not compile:
> 
> #include "hashtable.hpp"
> int main() {
>   Hashtable<int> h(nullptr, 10);
>   int i = 42;
>   h.put("foo", i);
> }
> h.cpp:5:16: error: rvalue reference to type 'int' cannot bind to lvalue of type 'int'
>     5 |   h.put("foo", i);
>       |                ^
> src/java.base/share/native/libcrexec/hashtable.hpp:47:33: note: passing argument to parameter 'value' here
>    47 |   bool put(const char *key, T&& value);
>       |                                 ^
> 1 error generated.
> 
> Couldn't we use a new template parameter for the method?
> [tu.patch](https://github.com/user-attachments/files/22741639/tu.patch)

You are right, it didn't work when I've tried to pass lvalue references in a test (and thanks to testing separately I found a bug in the list impl itself...). While this is not critical for CRaC itself I took the opportunity to improve my C++ knowledge and do the structures right :) Here is a standalone check to ensure that the containers work as expected: https://gist.github.com/rvansa/5f4cb76ddb4f694d2feb9a1ffb09d630
Note that I use two methods in `linkedlist.hpp` rather than universal reference in the end, as the universal reference template would consider `{ ... }` a braced initializer list rather than a struct initializer.

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

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

From duke at openjdk.org  Tue Oct  7 12:04:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 12:04:47 GMT
Subject: git: openjdk/crac: 8367975_checkpoint_pattern: 2 new changesets
Message-ID: <dbabb653-7df0-49a8-b588-4b8810b78334@openjdk.org>

Changeset: b117ca19
Branch: 8367975_checkpoint_pattern
Author:    Radim Vansa <rvansa at azul.com>
Date:      2025-10-02 11:48:34 +0000
URL:       https://git.openjdk.org/crac/commit/b117ca191bd1f1aef6ed347d2d22de839462a655

Fix build & test

! src/hotspot/share/runtime/crac.cpp
! test/jdk/jdk/crac/PathPatternTest.java

Changeset: fea2f6d8
Branch: 8367975_checkpoint_pattern
Author:    Radim Vansa <rvansa at azul.com>
Date:      2025-10-06 11:03:11 +0000
URL:       https://git.openjdk.org/crac/commit/fea2f6d85f5c029e16ad77a9fa0d3e176a3df25d

Review comments

! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/share/runtime/crac.cpp
! src/hotspot/share/runtime/globals.hpp
! src/java.base/share/man/java.md


From rvansa at openjdk.org  Tue Oct  7 12:07:08 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:07:08 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v6]
In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
Message-ID: <RR1w-RibejCKHehYAfgIHKUOLJ-YSA8xfMMxPX5krE8=.2ddae639-5dc2-418a-846b-f9b75c453a18@github.com>

> Add support for pattern in `CRaCCheckpointTo` VM option.

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Review comments
 - Fix build & test

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

Changes:
  - all: https://git.openjdk.org/crac/pull/264/files
  - new: https://git.openjdk.org/crac/pull/264/files/d5f1cc35..fea2f6d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=264&range=05
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=264&range=04-05

  Stats: 45 lines in 6 files changed: 18 ins; 4 del; 23 mod
  Patch: https://git.openjdk.org/crac/pull/264.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264

PR: https://git.openjdk.org/crac/pull/264

From rvansa at openjdk.org  Tue Oct  7 12:07:10 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:07:10 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v4]
In-Reply-To: <c38rYGy7MH--Gm_Uxi2yZRBFh7yIrSRLH9wPXOWLZlo=.88e8ab6d-afc8-42be-96a7-3b66e4356ea7@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
 <BA1RIpr8j3RC6AAyez9aJ_i3EvJWT3-ChATThy6LlLU=.7116ab01-5375-467d-b755-bf56bd7e3b69@github.com>
 <lxE-9JWhnLbOJ0X4payNYtxmAyKO61tsB8Rrf5qiV5o=.bd396c96-aef6-4600-a2d5-6d6cdd794ee9@github.com>
 <c38rYGy7MH--Gm_Uxi2yZRBFh7yIrSRLH9wPXOWLZlo=.88e8ab6d-afc8-42be-96a7-3b66e4356ea7@github.com>
Message-ID: <KIk9r-If_6bFWeXGcnESi4UbJGVTNnf8KuGO27ak1BQ=.346f3d68-325b-4a99-9785-42da3c714321@github.com>

On Thu, 2 Oct 2025 09:38:10 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Looks like when I've created the PR from a branch in this repository the GHA with tests is not executed. Pushed the code to my repo, too, tests running here: https://github.com/rvansa/crac/actions/runs/18130706409
>
> @rvansa There are still build and test failures in your repo

@TimPushkin I hope I have addressed these, and a green build in CI is here: https://github.com/rvansa/crac/actions/runs/18275647535

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

PR Comment: https://git.openjdk.org/crac/pull/264#issuecomment-3376578954

From rvansa at openjdk.org  Tue Oct  7 12:11:41 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:11:41 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v7]
In-Reply-To: <Jgljamknx2r90KSrWnbOAe7eSrisWjwIsrYWRRhFipw=.0eae009e-73b9-4ebf-b95e-e88f8dd0c1af@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <Jgljamknx2r90KSrWnbOAe7eSrisWjwIsrYWRRhFipw=.0eae009e-73b9-4ebf-b95e-e88f8dd0c1af@github.com>
Message-ID: <CWs_npIpBBIWsCIqryDvai2N47GqJs2OwAQTVb0hI8U=.b3e5e218-8cce-4ac3-8dba-b3da6d1f724c@github.com>

On Tue, 7 Oct 2025 12:03:55 GMT, Radim Vansa <rvansa 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).
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixup
>  - Review update

Apologies for my sloppiness on memory allocation.

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

PR Comment: https://git.openjdk.org/crac/pull/266#issuecomment-3376600292

From rvansa at openjdk.org  Tue Oct  7 12:11:43 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:11:43 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <Ib1vM3SxnOaYx-e9Lk_0Nuk4RSf1t439LjE28a8fSm4=.60772cab-44bc-41af-876b-4de683fd3756@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
 <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
 <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>
 <7roBfqhr2JZOllt4aL9WWofFJaPxXRvmFTGncmJ60M4=.6f06354b-5611-41f4-8ad1-8fd9984d61e6@github.com>
 <Ib1vM3SxnOaYx-e9Lk_0Nuk4RSf1t439LjE28a8fSm4=.60772cab-44bc-41af-876b-4de683fd3756@github.com>
Message-ID: <d2mfu4r5v5u5nDV5CfORavM2Uqms3sPNVOuiDeyAGug=.ac94a49f-240d-4056-a964-27195f648173@github.com>

On Tue, 7 Oct 2025 11:57:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>>> This should be a idiomatic use of perfect forwarding, since `T` is deduced the `T &&` is a universal reference and is treated as lvalue, depending on its use. The current code copies the argument; for `std::move` I would have to pass rvalue reference (therefore the method wouldn't be usable with const value). Sources:
>> 
>> One can try it does not compile:
>> 
>> #include "hashtable.hpp"
>> int main() {
>>   Hashtable<int> h(nullptr, 10);
>>   int i = 42;
>>   h.put("foo", i);
>> }
>> h.cpp:5:16: error: rvalue reference to type 'int' cannot bind to lvalue of type 'int'
>>     5 |   h.put("foo", i);
>>       |                ^
>> src/java.base/share/native/libcrexec/hashtable.hpp:47:33: note: passing argument to parameter 'value' here
>>    47 |   bool put(const char *key, T&& value);
>>       |                                 ^
>> 1 error generated.
>> 
>> Couldn't we use a new template parameter for the method?
>> [tu.patch](https://github.com/user-attachments/files/22741639/tu.patch)
>
> You are right, it didn't work when I've tried to pass lvalue references in a test (and thanks to testing separately I found a bug in the list impl itself...). While this is not critical for CRaC itself I took the opportunity to improve my C++ knowledge and do the structures right :) Here is a standalone check to ensure that the containers work as expected: https://gist.github.com/rvansa/5f4cb76ddb4f694d2feb9a1ffb09d630
> Note that I use two methods in `linkedlist.hpp` rather than universal reference in the end, as the universal reference template would consider `{ ... }` a braced initializer list rather than a struct initializer.

With the last change I can't use aggregate initializer anyway as the move ctor is defined :-/ Good ol' Java.

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

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

From rvansa at openjdk.org  Tue Oct  7 12:11:49 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 12:11:49 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
Message-ID: <A2htWLJXN9uI6gMxKahcCTcTnSPoc5Qe_lmDxo0bXEM=.7d17e648-ccbb-4014-8f57-2c573d08db15@github.com>

On Fri, 3 Oct 2025 11:23:38 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NoCPUFeaturesTest
>
> src/java.base/share/native/libcrexec/image_constraints.cpp line 146:
> 
>> 144:   while (fgets(line, sizeof(line), f)) {
>> 145:     char *eq = strchr(line, '=');
>> 146:     char *nl = strchr(eq + 1, '\n');
> 
> I believe parsing will be broken if `=` is encountered in the tag name itself. Same for `\n` although that is less likely.

Added extra checks when the tag is added.

> src/java.base/share/native/libcrexec/image_constraints.hpp line 95:
> 
>> 93:   const size_t _max_value_length = 256;
>> 94: 
>> 95:   bool check_tag(const char *name) {
> 
> "check" has too broad meaning IMO
> Suggestion:
> 
>   bool has_tag(const char *name) const {

I kept the `check_tag` name because it's checking more things in the end...

> src/java.base/share/native/libcrexec/linkedlist.hpp line 74:
> 
>> 72:       node = node->_next;
>> 73:     }
>> 74:   }
> 
> I don't insist but implementing an `std::iterator` does not seem too cumbersome and would allow to use the normal for loop

I personally find the lambda more convenient.

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

PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2410406373
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2410404280
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2410396963

From jkratochvil at openjdk.org  Tue Oct  7 12:32:22 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 7 Oct 2025 12:32:22 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v4]
In-Reply-To: <d2mfu4r5v5u5nDV5CfORavM2Uqms3sPNVOuiDeyAGug=.ac94a49f-240d-4056-a964-27195f648173@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <peS7Gq-n0BimK7-4j2TK2L4Aox4GZGHzUikjIXnrw9A=.f7dde1a0-8fe5-4c25-80db-53f81a6b26ab@github.com>
 <ygd-vpdTz1656sCzBf91CcVjqT2PTn8AN_w-XoAkKIU=.c5cd77eb-133b-483d-ac4c-5f948b6ead10@github.com>
 <r1VPT7iS0D1Bg9vYpIeev520Mp2ewi31WO9H9r953fs=.aacd552a-cb72-46ce-9c26-ef1bdfbb515c@github.com>
 <0J1BuUIKoz5g8tXKHc85OM0c0CBWfJyjnctqNpTKW-I=.3cf1d1ae-d0b0-4d06-853d-e65ea857e842@github.com>
 <OQulGsaIfvcNKKuHuqqy5A74hF7u3nf-c85JjPoei6M=.496cf833-c0c8-428a-8e27-4cc5314e2ab9@github.com>
 <7roBfqhr2JZOllt4aL9WWofFJaPxXRvmFTGncmJ60M4=.6f06354b-5611-41f4-8ad1-8fd9984d61e6@github.com>
 <Ib1vM3SxnOaYx-e9Lk_0Nuk4RSf1t439LjE28a8fSm4=.60772cab-44bc-41af-876b-4de683fd3756@github.com>
 <d2mfu4r5v5u5nDV5CfORavM2Uqms3sPNVOuiDeyAGug=.ac94a49f-240d-4056-a964-27195f648173@github.com>
Message-ID: <ub1s3gid5gN2mJFPJ4rfc0ZlYICA3StK8id2xhMjX5I=.4a604058-3644-49a7-8b38-85610e647585@github.com>

On Tue, 7 Oct 2025 12:06:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> You are right, it didn't work when I've tried to pass lvalue references in a test (and thanks to testing separately I found a bug in the list impl itself...). While this is not critical for CRaC itself I took the opportunity to improve my C++ knowledge and do the structures right :) Here is a standalone check to ensure that the containers work as expected: https://gist.github.com/rvansa/5f4cb76ddb4f694d2feb9a1ffb09d630
>> Note that I use two methods in `linkedlist.hpp` rather than universal reference in the end, as the universal reference template would consider `{ ... }` a braced initializer list rather than a struct initializer.
>
> With the last change I can't use aggregate initializer anyway as the move ctor is defined :-/ Good ol' Java.

It is an initializer list, one should not call it with an initializer list but rather just with the number itself. Up to you what calling conventions you want to support.

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

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

From rvansa at openjdk.org  Tue Oct  7 13:00:34 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 13:00:34 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v8]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <H8zwW5aVK25CKCETbjHvkIgVWw20TCLi21lOgLoUShA=.dd4c5452-bf28-4aed-9486-58e7beadeead@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Other platforms fixup

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/55c50f21..9215b872

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=07
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=06-07

  Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Tue Oct  7 13:12:15 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 13:12:15 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v9]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <efKnx3E7hpnfEC21IUcjgsfqD8QbEWI3PGOxkcCWdiQ=.ed1f8bef-cc7b-4708-a95a-9a208c8d8848@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Fixup

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/9215b872..46656342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=08
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Tue Oct  7 14:01:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 7 Oct 2025 14:01:31 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v10]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <MtWgXcMDi6xIFe3_56ZBrQuQoXZ6INYQuxFLvYnel6o=.675188da-903f-4c4d-ac2f-5a23385f4460@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Fix include problems

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/46656342..71ccd10c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=09
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=08-09

  Stats: 14 lines in 3 files changed: 6 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From tpushkin at openjdk.org  Wed Oct  8 07:51:55 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 8 Oct 2025 07:51:55 GMT
Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v6]
In-Reply-To: <RR1w-RibejCKHehYAfgIHKUOLJ-YSA8xfMMxPX5krE8=.2ddae639-5dc2-418a-846b-f9b75c453a18@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
 <RR1w-RibejCKHehYAfgIHKUOLJ-YSA8xfMMxPX5krE8=.2ddae639-5dc2-418a-846b-f9b75c453a18@github.com>
Message-ID: <YCHWfsX5PVD-BrfSsabrP-knAPMeVFl-dwwkQexW6oM=.a28a3067-251c-4323-a085-eb9e8acaf8c3@github.com>

On Tue, 7 Oct 2025 12:07:08 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Add support for pattern in `CRaCCheckpointTo` VM option.
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review comments
>  - Fix build & test

LGTM

src/hotspot/share/runtime/crac.cpp line 294:

> 292: #ifndef PATH_MAX
> 293: # define PATH_MAX 1024
> 294: #endif

Not critical, but we could also try `MAX_PATH` defined in Windows before falling back to a hard-coded value

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

Marked as reviewed by tpushkin (Committer).

PR Review: https://git.openjdk.org/crac/pull/264#pullrequestreview-3313385914
PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2412866979

From rvansa at openjdk.org  Wed Oct  8 07:56:01 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 8 Oct 2025 07:56:01 GMT
Subject: [crac] Integrated: 8367975: [CRaC] Pattern in CRaCCheckpointTo
In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com>
Message-ID: <vJxaHnY8BqIt9b9QO5V0M0qRzIf3f19AOu6k3U2jVyM=.73707aba-f424-4d6b-a20c-be24fea60f5b@github.com>

On Thu, 18 Sep 2025 09:22:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Add support for pattern in `CRaCCheckpointTo` VM option.

This pull request has now been integrated.

Changeset: b47bafb4
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/b47bafb42dfd1d274cb85e6b7b7a38e7af01fa80
Stats:     505 lines in 16 files changed: 441 ins; 29 del; 35 mod

8367975: [CRaC] Pattern in CRaCCheckpointTo

Reviewed-by: tpushkin

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

PR: https://git.openjdk.org/crac/pull/264

From rmarchenko at openjdk.org  Wed Oct  8 08:31:55 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 8 Oct 2025 08:31:55 GMT
Subject: [crac] RFR: 8369394: [CRaC] java.nio.channels.ClosedSelectorException
 in sun.nio.ch.SelectorImpl.ensureOpen
Message-ID: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>

Suppress `RuntimeException` as it can be thrown by `Selector.select()` method.

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

Commit messages:
 - Suppress RuntimeException

Changes: https://git.openjdk.org/crac/pull/267/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=267&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369394
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/crac/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/267/head:pull/267

PR: https://git.openjdk.org/crac/pull/267

From rvansa at openjdk.org  Wed Oct  8 08:56:58 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 8 Oct 2025 08:56:58 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen
In-Reply-To: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
Message-ID: <pE06hSjqNZMxIxeuA4jLZxlrH_C5AsLJ6DwULwQPYu0=.f5846885-4e1b-4e04-bdc6-711ab6ee8d93@github.com>

On Wed, 8 Oct 2025 08:23:30 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Suppress `RuntimeException` as it can be thrown by `Selector.select()` method.

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 89:

> 87:             try {
> 88:                 selector.select(1);
> 89:             } catch (IOException | RuntimeException e) {

I am worried that suppressing exceptions beyond `ClosedSelectorException` could hide a future underlying problem. Do you have a strong reason to suppress also NPEs, for instance?

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

PR Review Comment: https://git.openjdk.org/crac/pull/267#discussion_r2413111382

From tpushkin at openjdk.org  Wed Oct  8 09:56:46 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 8 Oct 2025 09:56:46 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v10]
In-Reply-To: <MtWgXcMDi6xIFe3_56ZBrQuQoXZ6INYQuxFLvYnel6o=.675188da-903f-4c4d-ac2f-5a23385f4460@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <MtWgXcMDi6xIFe3_56ZBrQuQoXZ6INYQuxFLvYnel6o=.675188da-903f-4c4d-ac2f-5a23385f4460@github.com>
Message-ID: <z_0J0hcFS5tayTkV85PfY2KqoZAtnNwrWVR46xGQPHo=.40662a8a-8898-45f0-9944-116a2b95aa2b@github.com>

On Tue, 7 Oct 2025 14:01:31 GMT, Radim Vansa <rvansa 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).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix include problems

src/hotspot/share/runtime/crac.cpp line 107:

> 105: 
> 106:   // If this is a second checkpoint we should use a clear configuration
> 107:   if (_generation != 0 && !_engine->reset_conf()) {

Generation numbering starts from 1, so it should be `_generation > 1`

src/hotspot/share/runtime/crac.cpp line 107:

> 105: 
> 106:   // If this is a second checkpoint we should use a clear configuration
> 107:   if (_generation != 0 && !_engine->reset_conf()) {

Why do we need to reset the configuration now? Is it because user data is auto-reset while the tags are not? Ideally they should act the same to make the behavior more predictable. IMO it would be better if both were kept until explicitly cleared by the user, if that is possible. But that would require updating the user data API probably...

Anyway, shouldn't the CPU features stay the same between checkpoints? Then it would be more efficient to set them only on the first checkpoint instead of resetting the whole configuration each time.

src/java.base/share/native/libcrexec/hashtable.hpp line 136:

> 134: 
> 135: template<class T> template<typename TT>
> 136: bool Hashtable<T>::put(const char* key, TT&& value) {

A total nitpick, but now we have `const char *key` in the declaration and `const char* key` in the definition. When I was rewriting crexec into C++ I used the `type *x`, `type * const x` style everywhere. But since there is no linter for this in CI it seems that there is no sense in trying to keep it in a single style, it will diverge with time anyway...

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

> 65:   }
> 66:   if (strlen(name) >= _MAX_NAME_SIZE) {
> 67:     fprintf(stderr, CREXEC "%s %s is too long\n", type, name);

Would be a better UX if we specify how many symbols is allowed
Suggestion:

    fprintf(stderr, CREXEC "%s %s name is too long, at most %zu chars allowed\n", type, name, _MAX_NAME_SIZE - 1;

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

> 68:     return false;
> 69:   }
> 70:   if (value_size >= _MAX_VALUE_SIZE) {

I think it should be:
Suggestion:

  if (value_size > _MAX_VALUE_SIZE) {

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

> 69:   }
> 70:   if (value_size >= _MAX_VALUE_SIZE) {
> 71:       fprintf(stderr, CREXEC "%s %s value is too long (%zu bytes)\n", type, name, value_size);

Suggestion:

      fprintf(stderr, CREXEC "%s %s value is too long: %zu bytes > %zu allowed\n", type, name, value_size, _MAX_VALUE_SIZE);

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

> 138: }
> 139: 
> 140: static inline unsigned char from_hex(char c, bool& err) {

I'd say it's a better style to take a pointer when you plan to write into the argument since that becomes more obvious at the call site, but this is opinionated

src/java.base/share/native/libcrexec/image_constraints.hpp line 129:

> 127:   }
> 128: 
> 129:   bool is_failed(const char* name) {

Suggestion:

  bool is_failed(const char* name) const {

src/java.base/share/native/libcrexec/linkedlist.hpp line 55:

> 53:     } else {
> 54:       _tail = node;
> 55:     }

Suggestion:

    if (_tail) {
      _tail->_next = node;
    }
    _tail = node;

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

PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413008490
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413057655
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413154149
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413235569
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413241858
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413240096
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413265426
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413186999
PR Review Comment: https://git.openjdk.org/crac/pull/266#discussion_r2413123902

From rmarchenko at openjdk.org  Wed Oct  8 14:45:29 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 8 Oct 2025 14:45:29 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen
In-Reply-To: <pE06hSjqNZMxIxeuA4jLZxlrH_C5AsLJ6DwULwQPYu0=.f5846885-4e1b-4e04-bdc6-711ab6ee8d93@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
 <pE06hSjqNZMxIxeuA4jLZxlrH_C5AsLJ6DwULwQPYu0=.f5846885-4e1b-4e04-bdc6-711ab6ee8d93@github.com>
Message-ID: <NAkOued0BmMx6XjUJqIkFyobPejFuMsCQ3rNmGtAmOg=.4345cec0-dece-4a2a-ba7b-5d3e2496d180@github.com>

On Wed, 8 Oct 2025 08:53:41 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Suppress `RuntimeException` as it can be thrown by `Selector.select()` method.
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 89:
> 
>> 87:             try {
>> 88:                 selector.select(1);
>> 89:             } catch (IOException | RuntimeException e) {
> 
> I am worried that suppressing exceptions beyond `ClosedSelectorException` could hide a future underlying problem. Do you have a strong reason to suppress also NPEs, for instance?

I have no strong reasons, I was thinking it could throw RuntimeException derived exceptions, like IllegalStateException, IllegalArgumentException, and ClosedSelectorException, so we can suppress them all, as it is just a "push" for a Selector here.

But you're right, we could miss something important doing this way, so I can replace it with ClosedSelectorException.

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

PR Review Comment: https://git.openjdk.org/crac/pull/267#discussion_r2414105295

From rmarchenko at openjdk.org  Thu Oct  9 06:35:10 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 9 Oct 2025 06:35:10 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen [v2]
In-Reply-To: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
Message-ID: <keKvJi0lP9FGcFSeG5rWUIRvYPBkDUb1Z2_XYLxacVA=.ccb66264-72df-4510-965e-e300ed75bc57@github.com>

> Suppress `RuntimeException` as it can be thrown by `Selector.select()` method.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  fixed review comments

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

Changes:
  - all: https://git.openjdk.org/crac/pull/267/files
  - new: https://git.openjdk.org/crac/pull/267/files/c14f9b25..76e3c332

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=267&range=01
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=267&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/crac/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/267/head:pull/267

PR: https://git.openjdk.org/crac/pull/267

From rmarchenko at openjdk.org  Thu Oct  9 06:38:50 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 9 Oct 2025 06:38:50 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen [v2]
In-Reply-To: <NAkOued0BmMx6XjUJqIkFyobPejFuMsCQ3rNmGtAmOg=.4345cec0-dece-4a2a-ba7b-5d3e2496d180@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
 <pE06hSjqNZMxIxeuA4jLZxlrH_C5AsLJ6DwULwQPYu0=.f5846885-4e1b-4e04-bdc6-711ab6ee8d93@github.com>
 <NAkOued0BmMx6XjUJqIkFyobPejFuMsCQ3rNmGtAmOg=.4345cec0-dece-4a2a-ba7b-5d3e2496d180@github.com>
Message-ID: <eoeaz1EYfOHz3SYOJp_j5_qehCNAgOpO3AOvnIGm3mM=.fdc4c6df-632a-4904-9a6a-90a2071d9124@github.com>

On Wed, 8 Oct 2025 14:42:53 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 89:
>> 
>>> 87:             try {
>>> 88:                 selector.select(1);
>>> 89:             } catch (IOException | RuntimeException e) {
>> 
>> I am worried that suppressing exceptions beyond `ClosedSelectorException` could hide a future underlying problem. Do you have a strong reason to suppress also NPEs, for instance?
>
> I have no strong reasons, I was thinking it could throw RuntimeException derived exceptions, like IllegalStateException, IllegalArgumentException, and ClosedSelectorException, so we can suppress them all, as it is just a "push" for a Selector here.
> 
> But you're right, we could miss something important doing this way, so I can replace it with ClosedSelectorException.

done

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

PR Review Comment: https://git.openjdk.org/crac/pull/267#discussion_r2415709592

From rvansa at openjdk.org  Thu Oct  9 14:09:40 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 9 Oct 2025 14:09:40 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen [v2]
In-Reply-To: <keKvJi0lP9FGcFSeG5rWUIRvYPBkDUb1Z2_XYLxacVA=.ccb66264-72df-4510-965e-e300ed75bc57@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
 <keKvJi0lP9FGcFSeG5rWUIRvYPBkDUb1Z2_XYLxacVA=.ccb66264-72df-4510-965e-e300ed75bc57@github.com>
Message-ID: <zVWX74wu1uDy75Sx5pgY7u7glyNJCvyEg9jPKUjuUyw=.08374611-4196-47d8-ad72-18428348a22b@github.com>

On Thu, 9 Oct 2025 06:35:10 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Suppress `ClosedSelectorException` as it can be thrown by `Selector.select()` method.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed review comments

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/267#pullrequestreview-3319161756

From duke at openjdk.org  Thu Oct  9 14:09:40 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Oct 2025 14:09:40 GMT
Subject: [crac] RFR: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen [v2]
In-Reply-To: <keKvJi0lP9FGcFSeG5rWUIRvYPBkDUb1Z2_XYLxacVA=.ccb66264-72df-4510-965e-e300ed75bc57@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
 <keKvJi0lP9FGcFSeG5rWUIRvYPBkDUb1Z2_XYLxacVA=.ccb66264-72df-4510-965e-e300ed75bc57@github.com>
Message-ID: <DG6IT2-CSNaG5I2-6HijQLvbIt3PZc8QA3tGgNryJc4=.4bd1e317-0ac9-414d-a622-9ce013ba20a5@github.com>

On Thu, 9 Oct 2025 06:35:10 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Suppress `ClosedSelectorException` as it can be thrown by `Selector.select()` method.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed review comments

@wkia 
Your change (at version 76e3c33219b429b23d83d66f3abd273dc781a590) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/267#issuecomment-3386044533

From rvansa at openjdk.org  Thu Oct  9 14:26:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 9 Oct 2025 14:26:31 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v10]
In-Reply-To: <z_0J0hcFS5tayTkV85PfY2KqoZAtnNwrWVR46xGQPHo=.40662a8a-8898-45f0-9944-116a2b95aa2b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <MtWgXcMDi6xIFe3_56ZBrQuQoXZ6INYQuxFLvYnel6o=.675188da-903f-4c4d-ac2f-5a23385f4460@github.com>
 <z_0J0hcFS5tayTkV85PfY2KqoZAtnNwrWVR46xGQPHo=.40662a8a-8898-45f0-9944-116a2b95aa2b@github.com>
Message-ID: <fOTE7JDr-_WKfkwUQBul93cs1yc86CpB_Na3lEEuR3s=.c66c1e04-a7ad-4510-b0ff-ac802747bfeb@github.com>

On Wed, 8 Oct 2025 08:36:43 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix include problems
>
> src/hotspot/share/runtime/crac.cpp line 107:
> 
>> 105: 
>> 106:   // If this is a second checkpoint we should use a clear configuration
>> 107:   if (_generation != 0 && !_engine->reset_conf()) {
> 
> Why do we need to reset the configuration now? Is it because user data is auto-reset while the tags are not? Ideally they should act the same to make the behavior more predictable. IMO it would be better if both were kept until explicitly cleared by the user, if that is possible. But that would require updating the user data API probably...
> 
> Anyway, shouldn't the CPU features stay the same between checkpoints? Then it would be more efficient to set them only on the first checkpoint instead of resetting the whole configuration each time.

Hmm, the reset was there to prevent errors coming from setting the CPU features second time, but you're right that rather than that we could just avoid setting them in the second checkpoint.

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

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

From rmarchenko at openjdk.org  Thu Oct  9 14:28:55 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 9 Oct 2025 14:28:55 GMT
Subject: [crac] Integrated: 8369394: [CRaC]
 java.nio.channels.ClosedSelectorException in
 sun.nio.ch.SelectorImpl.ensureOpen
In-Reply-To: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
References: <d0i1O7ulgg86MEdeDiG3Dujb5FQw9loHpHsbvvdENv8=.08e0623e-0f6b-4f34-9256-c35af6975ecc@github.com>
Message-ID: <8eB__SsTi7pXuwFafRAVn1VnR67NFLRlY6f6GRzJ28M=.a5781a15-417a-4d81-baee-eca139ce5ad8@github.com>

On Wed, 8 Oct 2025 08:23:30 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> Suppress `ClosedSelectorException` as it can be thrown by `Selector.select()` method.

This pull request has now been integrated.

Changeset: a6adb7d3
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/a6adb7d30320e6933d8dd93fedaf6c8aeac5cc7d
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8369394: [CRaC] java.nio.channels.ClosedSelectorException in sun.nio.ch.SelectorImpl.ensureOpen

Reviewed-by: rvansa

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

PR: https://git.openjdk.org/crac/pull/267

From rvansa at openjdk.org  Thu Oct  9 14:33:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 9 Oct 2025 14:33:00 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v11]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <TepvDmTqVF3yZSP8WAFM0cn3mW2tWMvodYQlsHqFl1o=.ad1ce4bb-6cd2-4fce-85fa-3e42b9bb3a48@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/71ccd10c..cc676f7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=10
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=09-10

  Stats: 8 lines in 3 files changed: 1 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Fri Oct 10 07:33:48 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 10 Oct 2025 07:33:48 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v11]
In-Reply-To: <z_0J0hcFS5tayTkV85PfY2KqoZAtnNwrWVR46xGQPHo=.40662a8a-8898-45f0-9944-116a2b95aa2b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <MtWgXcMDi6xIFe3_56ZBrQuQoXZ6INYQuxFLvYnel6o=.675188da-903f-4c4d-ac2f-5a23385f4460@github.com>
 <z_0J0hcFS5tayTkV85PfY2KqoZAtnNwrWVR46xGQPHo=.40662a8a-8898-45f0-9944-116a2b95aa2b@github.com>
Message-ID: <lisY16HihXcC7gJu2AAXRq7nUgf7wZPFy8BRMNjtCfY=.a5e7eb61-9618-4fc1-b841-dee8b2f1c8f6@github.com>

On Wed, 8 Oct 2025 09:09:17 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>
>
> src/java.base/share/native/libcrexec/hashtable.hpp line 136:
> 
>> 134: 
>> 135: template<class T> template<typename TT>
>> 136: bool Hashtable<T>::put(const char* key, TT&& value) {
> 
> A total nitpick, but now we have `const char *key` in the declaration and `const char* key` in the definition. When I was rewriting crexec into C++ I used the `type *x`, `type * const x` style everywhere. But since there is no linter for this in CI it seems that there is no sense in trying to keep it in a single style, it will diverge with time anyway...

To me, it makes little sense to use `T&& x` and `T *x`, and we should be consistent at least on the file level. And yes, without linting I'll always forget it somewhere...

While I personally prefer `T *x`, from some recent mainline JDK PRs I think that the project prefers `T* x`, so let's use that.

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

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

From rvansa at openjdk.org  Fri Oct 10 08:36:39 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 10 Oct 2025 08:36:39 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v12]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <tVmqsfKUzvz_Ig0FWT9SVi_wdSx7dD-Cabdo1WOQP6Q=.a367261c-c331-4be3-9a10-029fed06a2a4@github.com>

> 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).

Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Improve crlib docs
 - Merge remote-tracking branch 'origin/crac' into 8368929_external_cpu_features
 - Apply suggestions from code review
   
   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>
 - Fix include problems
 - Fixup
 - Other platforms fixup
 - Fixup
 - Review update
 - Fix windows build
 - Reset conf before 2nd checkpoint
 - ... and 5 more: https://git.openjdk.org/crac/compare/a6adb7d3...9c0464f9

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

Changes: https://git.openjdk.org/crac/pull/266/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=266&range=11
  Stats: 972 lines in 22 files changed: 767 ins; 82 del; 123 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266

From rvansa at openjdk.org  Fri Oct 10 09:06:35 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 10 Oct 2025 09:06:35 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v13]
In-Reply-To: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
Message-ID: <EyBhnsCSha7LUDRG3_oFrdlbkICvW1DFh7Oq1QZZCqs=.ef465412-b69a-4165-8f53-f562bf6e0146@github.com>

> 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).

Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:

  VM_Features use Zero_Features on non-x86

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

Changes:
  - all: https://git.openjdk.org/crac/pull/266/files
  - new: https://git.openjdk.org/crac/pull/266/files/9c0464f9..ae6242cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=266&range=12
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=266&range=11-12

  Stats: 23 lines in 7 files changed: 5 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/crac/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266

PR: https://git.openjdk.org/crac/pull/266