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

From tpushkin at openjdk.org  Fri Oct 10 19:38:44 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 10 Oct 2025 19:38:44 GMT
Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine
 [v13]
In-Reply-To: <EyBhnsCSha7LUDRG3_oFrdlbkICvW1DFh7Oq1QZZCqs=.ef465412-b69a-4165-8f53-f562bf6e0146@github.com>
References: <MYCFPqq5C77T83dB4JeCULRBVBT-vOrAxBi-VnqNfMI=.92f68c73-99bd-4460-bd18-3fc29aff790b@github.com>
 <EyBhnsCSha7LUDRG3_oFrdlbkICvW1DFh7Oq1QZZCqs=.ef465412-b69a-4165-8f53-f562bf6e0146@github.com>
Message-ID: <Zut6DFAcIr0JVDt0JHY-FAHK2D2ZZis-gcsbPJxBShM=.76bccef8-22c3-4f3b-8384-fd19be638c14@github.com>

On Fri, 10 Oct 2025 09:06:35 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:
> 
>   VM_Features use Zero_Features on non-x86

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/266#pullrequestreview-3325654217

From rvansa at openjdk.org  Mon Oct 13 07:11:49 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 13 Oct 2025 07:11:49 GMT
Subject: [crac] Integrated: 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: <jH-8SC-Qw4LihU7NsZhqcjLAw4cuaudIsMAaJPJcLC8=.0218ad3e-cdc3-4f1a-ad3f-3165974b3ed6@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).

This pull request has now been integrated.

Changeset: 3260337b
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/3260337b25ecb9198ad75af3ccc59272c0ffaa86
Stats:     989 lines in 23 files changed: 772 ins; 94 del; 123 mod

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

Reviewed-by: tpushkin

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

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

From rvansa at openjdk.org  Mon Oct 13 07:12:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 13 Oct 2025 07:12:31 GMT
Subject: git: openjdk/crac: crac: 8368929: [CRaC] Move CPUFeatures check to C/R
 engine
Message-ID: <3e6b1af7-744e-47d2-83cb-643d08e23ae9@openjdk.org>

Changeset: 3260337b
Branch: crac
Author:    Radim Vansa <rvansa at openjdk.org>
Date:      2025-10-13 07:09:08 +0000
URL:       https://git.openjdk.org/crac/commit/3260337b25ecb9198ad75af3ccc59272c0ffaa86

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

Reviewed-by: tpushkin

! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp
! src/hotspot/cpu/arm/vm_version_arm.hpp
! src/hotspot/cpu/ppc/vm_version_ppc.hpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp
! src/hotspot/cpu/s390/vm_version_s390.hpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/zero/vm_version_zero.hpp
+ src/hotspot/share/include/crlib/crlib_image_constraints.h
! src/hotspot/share/include/crlib/crlib_user_data.h
! src/hotspot/share/runtime/abstract_vm_version.hpp
! src/hotspot/share/runtime/crac.cpp
! src/hotspot/share/runtime/crac_engine.cpp
! src/hotspot/share/runtime/crac_engine.hpp
! src/hotspot/share/runtime/threads.cpp
! src/java.base/share/native/libcrexec/crexec.cpp
+ src/java.base/share/native/libcrexec/crexec.hpp
! src/java.base/share/native/libcrexec/hashtable.hpp
+ src/java.base/share/native/libcrexec/image_constraints.cpp
+ src/java.base/share/native/libcrexec/image_constraints.hpp
+ src/java.base/share/native/libcrexec/linkedlist.hpp
! test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh
! test/jdk/jdk/crac/ignoreRestore/NoCPUFeaturesTest.java


From jkratochvil at openjdk.org  Mon Oct 13 19:03:58 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 13 Oct 2025 19:03:58 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
Message-ID: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>

https://bugs.openjdk.org/browse/JDK-8369729

It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

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

Commit messages:
 - 8369729: [CRaC] CRaC restore fails with different CPUs

Changes: https://git.openjdk.org/crac/pull/268/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369729
  Stats: 37 lines in 2 files changed: 35 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/crac/pull/268.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/268/head:pull/268

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

From rvansa at openjdk.org  Tue Oct 14 09:21:50 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 14 Oct 2025 09:21:50 GMT
Subject: [crac] RFR: 8368929: CRaC: Record metrics during checkpoint
Message-ID: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>

CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

Commit messages:
 - 8368929: CRaC: Record metrics during checkpoint

Changes: https://git.openjdk.org/crac/pull/269/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368929
  Stats: 472 lines in 15 files changed: 417 ins; 22 del; 33 mod
  Patch: https://git.openjdk.org/crac/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/269/head:pull/269

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

From rvansa at openjdk.org  Tue Oct 14 09:37:02 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 14 Oct 2025 09:37:02 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
In-Reply-To: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
Message-ID: <oDOcMzkH6807EURKSrkAme7r6Cd80A5MOR66bOAy6wY=.77f8f8e0-82b0-4599-9bb0-fd3d8ff01346@github.com>

On Mon, 13 Oct 2025 18:57:43 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369729
> 
> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

Which case in `CPUFeatures.sh` does test this? Is this a disabled test (that could be enabled now?)

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

PR Comment: https://git.openjdk.org/crac/pull/268#issuecomment-3400951068

From rvansa at openjdk.org  Tue Oct 14 10:44:22 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 14 Oct 2025 10:44:22 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v2]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <rBg7MFohR6BOnMExQDl6mLtt-QtjRBZOF4iYYIQLjFA=.ffa1d656-a701-4e26-ac8f-6a5a5474c631@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Don't use __typeof__

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/1fcc12af..ab218518

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

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

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

From rvansa at openjdk.org  Tue Oct 14 10:44:23 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 14 Oct 2025 10:44:23 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <6ejznN5IKAiDihdRb3yBcySp0ts2D38ewNuwPED3mpA=.0e8bad4d-15ca-4b44-968e-e303eb3e4553@github.com>

On Tue, 14 Oct 2025 09:15:52 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

It seems that the `PathPatternTest` introduced in #264 is unstable :-/

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

PR Comment: https://git.openjdk.org/crac/pull/269#issuecomment-3401184993

From jkratochvil at openjdk.org  Tue Oct 14 13:55:49 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 14 Oct 2025 13:55:49 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
In-Reply-To: <oDOcMzkH6807EURKSrkAme7r6Cd80A5MOR66bOAy6wY=.77f8f8e0-82b0-4599-9bb0-fd3d8ff01346@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
 <oDOcMzkH6807EURKSrkAme7r6Cd80A5MOR66bOAy6wY=.77f8f8e0-82b0-4599-9bb0-fd3d8ff01346@github.com>
Message-ID: <MBR8YE91mFM-zrw0IEDY8DIJ9r1v7jt-aF7y8uXS06g=.71d8cd30-efe5-43e9-8e38-1f6069776ff6@github.com>

On Tue, 14 Oct 2025 09:34:40 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Which case in `CPUFeatures.sh` does test this? Is this a disabled test (that could be enabled now?)

This line should find it:

checkpoint_restore "kvm           IvyBridge"   "kvm           SandyBridge" - "-XX:CPUFeatures=0x142100054bbd7,0xc0" 

but even with this fix that testcase is still crashing. Maybe it is due to the still missing CPU Features (ZULU-82655):
- `CMPXCHG16B`
- `LAHF64_SAHF64`

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

PR Comment: https://git.openjdk.org/crac/pull/268#issuecomment-3402010657

From rvansa at openjdk.org  Wed Oct 15 09:04:35 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 15 Oct 2025 09:04:35 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Fix for PathPatternTest

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/ab218518..523661ab

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

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

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

From jkratochvil at openjdk.org  Wed Oct 15 19:30:12 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 15 Oct 2025 19:30:12 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
 [v2]
In-Reply-To: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
Message-ID: <bGUkbKAdhynpZ85sgqtPsLJT8YnhkJT1TavvchPRj6k=.7e4f4aa8-cb7d-4237-9487-3824206a0a04@github.com>

> https://bugs.openjdk.org/browse/JDK-8369729
> 
> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix CI failure

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

Changes:
  - all: https://git.openjdk.org/crac/pull/268/files
  - new: https://git.openjdk.org/crac/pull/268/files/ed764481..c8cb5be0

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

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

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

From jkratochvil at openjdk.org  Wed Oct 15 20:20:13 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 15 Oct 2025 20:20:13 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
 [v3]
In-Reply-To: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
Message-ID: <2RT4PJuSdiFg9l61vzIPAKercxv3RuHjfhKqpk5HVc8=.ea06e93b-7c31-42e3-aed6-06afe31093e1@github.com>

> https://bugs.openjdk.org/browse/JDK-8369729
> 
> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Move errorMsg statement for easier disabling of various testcases

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

Changes:
  - all: https://git.openjdk.org/crac/pull/268/files
  - new: https://git.openjdk.org/crac/pull/268/files/c8cb5be0..624e09f1

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

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

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

From jkratochvil at openjdk.org  Thu Oct 16 06:09:27 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 16 Oct 2025 06:09:27 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
 [v4]
In-Reply-To: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
Message-ID: <SsZu-W3LblSTw0BlbApgM5hEHMRL7X83eHEbJhTioAA=.c59a3b0b-e57c-4fff-bc33-c68b87e8be10@github.com>

> https://bugs.openjdk.org/browse/JDK-8369729
> 
> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix CI failure

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

Changes:
  - all: https://git.openjdk.org/crac/pull/268/files
  - new: https://git.openjdk.org/crac/pull/268/files/624e09f1..6ef9a118

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

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

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

From jkratochvil at openjdk.org  Thu Oct 16 07:50:51 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 16 Oct 2025 07:50:51 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
In-Reply-To: <MBR8YE91mFM-zrw0IEDY8DIJ9r1v7jt-aF7y8uXS06g=.71d8cd30-efe5-43e9-8e38-1f6069776ff6@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
 <oDOcMzkH6807EURKSrkAme7r6Cd80A5MOR66bOAy6wY=.77f8f8e0-82b0-4599-9bb0-fd3d8ff01346@github.com>
 <MBR8YE91mFM-zrw0IEDY8DIJ9r1v7jt-aF7y8uXS06g=.71d8cd30-efe5-43e9-8e38-1f6069776ff6@github.com>
Message-ID: <yrsBJra5N091KVctN1hGjndpQNux0z2j9wnZw5tAkW0=.96854741-1588-425f-9b8f-ee7330244fd9@github.com>

On Tue, 14 Oct 2025 13:53:22 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Which case in `CPUFeatures.sh` does test this? Is this a disabled test (that could be enabled now?)

The `CPUFeatures.sh` testcases work even before this fix. Apparently `qemu-kvm -cpu` option does not have enough features/restrictions to reproduce it. Filed downstream ZULU-82680 for it.

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

PR Comment: https://git.openjdk.org/crac/pull/268#issuecomment-3409621419

From rvansa at openjdk.org  Thu Oct 16 08:16:17 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 16 Oct 2025 08:16:17 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
Message-ID: <bljopgGI09xEMl4rkDNqpupiZh9tjUXnmVagqteFN3o=.ad7bf1de-6eeb-4d86-8de4-5d645dd91656@github.com>

On Wed, 15 Oct 2025 09:04:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for PathPatternTest

@TimPushkin I've piggy-backed a fix in `PathPatternTest`, so now this is green. Could you give an ETA on review, please?

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

PR Comment: https://git.openjdk.org/crac/pull/269#issuecomment-3409722731

From tpushkin at openjdk.org  Thu Oct 16 08:19:29 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 16 Oct 2025 08:19:29 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <bljopgGI09xEMl4rkDNqpupiZh9tjUXnmVagqteFN3o=.ad7bf1de-6eeb-4d86-8de4-5d645dd91656@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <bljopgGI09xEMl4rkDNqpupiZh9tjUXnmVagqteFN3o=.ad7bf1de-6eeb-4d86-8de4-5d645dd91656@github.com>
Message-ID: <Jws9_nd4fYzDfOrhw-WCBe6X509svLGAFKC7xZZhyYA=.df34f911-25b6-45c7-9ff5-f7e7919128e7@github.com>

On Thu, 16 Oct 2025 08:13:24 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for PathPatternTest
>
> @TimPushkin I've piggy-backed a fix in `PathPatternTest`, so now this is green. Could you give an ETA on review, please?

@rvansa I'll try to look today, if the time allows; otherwise, I'll look tomorrow.

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

PR Comment: https://git.openjdk.org/crac/pull/269#issuecomment-3409735048

From tpushkin at openjdk.org  Thu Oct 16 14:21:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 16 Oct 2025 14:21:17 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
Message-ID: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>

On Wed, 15 Oct 2025 09:04:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for PathPatternTest

There should be some way for the user to know which metrics are available because the names will be needed to write a selection policy. Ideally some documentation for the value ranges is also needed.

src/hotspot/share/prims/jvm.cpp line 3726:

> 3724: JVM_END
> 3725: 
> 3726: 

Redundant empty line

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

> 713:   ResourceMark rm;
> 714:   objArrayOop metrics_oops = objArrayOop(JNIHandles::resolve_non_null(metrics));
> 715:   typeArrayOop values_oops = typeArrayOop(JNIHandles::resolve_non_null(values));

To be clearer that these are just casts and not construction+copy
Suggestion:

  const auto metrics_oops = static_cast<objArrayOop>(JNIHandles::resolve_non_null(metrics));
  const auto values_oops = static_cast<typeArrayOop>(JNIHandles::resolve_non_null(values));

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

> 731: 
> 732:   double uptime = TimeHelper::counter_to_millis(os::elapsed_counter());
> 733:   result = result && _engine->set_score("vm.boot_time", os::javaTimeMillis() - uptime);

Shouldn't `boot_time()` use `TimeHelper` too?

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

> 744:   result = result && _engine->set_score("java.cls.sharedUnloadedClasses", shared_unloaded_classes);
> 745: #endif // INCLUDE_MANAGEMENT
> 746:   result = result && _engine->set_score("sun.cls.appClassLoadCount", ClassLoader::perf_app_classload_count()->get_value());

`ClassLoader::perf_app_classload_count()` should return null when `UsePerfData` is false. Worth to check the other counters too.

src/hotspot/share/runtime/crac.hpp line 44:

> 42:   static Handle checkpoint(jarray fd_arr, jobjectArray obj_arr, bool dry_run, jlong jcmd_stream, TRAPS);
> 43:   static bool is_image_score_supported();
> 44:   static bool record_image_score(jobjectArray metrics, jdoubleArray values);

Since they are closer to each other than to the checkpointing methods...
Suggestion:


  static bool is_image_score_supported();
  static bool record_image_score(jobjectArray metrics, jdoubleArray values);

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

> 389:   return ApiStatus::OK;
> 390: 
> 391: 

Excessive empty line

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

> 394:   require_method(set_restore_data)
> 395:   require_method(get_restore_data)
> 396:   complete_extension_api(_restore_data_api);

Suggestion:

  complete_extension_api(_restore_data_api)

src/hotspot/share/runtime/crac_engine.hpp line 76:

> 74: 
> 75:   ApiStatus prepare_image_score_api();
> 76:   bool set_score(const char* metric, double value);

Suggestion:

  bool set_score(const char* metric, double value) const;

src/java.base/share/classes/jdk/internal/crac/Score.java line 1:

> 1: package jdk.internal.crac;

Missing a license header

src/java.base/share/classes/jdk/internal/crac/Score.java line 41:

> 39:     private static native boolean record(String[] metrics, double[] values);
> 40: 
> 41:     static synchronized void record() {

Probably should also be private as it is intended for the resource only

src/java.base/share/classes/jdk/internal/crac/Score.java line 60:

> 58:      * recording metadata this is ignored.
> 59:      * On checkpoint the metrics are not reset; if that is desired invoke {@link #resetAll()}
> 60:      * manually.

BTW we should also be documenting this on the engine API level: whether something is reset on checkpoint or not. AFAIR user data is reset, constraints are not, scores ? I haven't checked yet. This can be postponed until we claim the support of repeated checkpoints, I am just saying.

src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 10:

> 8:     private static final String GLOBAL_CONTEXT_IMPL_PROP = "jdk.crac.globalContext.impl";
> 9: 
> 10:     public static class Score implements JDKResource {

Both `Score` and `GlobalContext` should have private constructors for clarity

src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 18:

> 16:             if (ctx instanceof OrderedContext<?> octx) {
> 17:                 jdk.internal.crac.Score.setScore("jdk.crac.globalContext.size", octx.size());
> 18:             }

I believe it should always be an `OrderedContext`, why not a cast then?

src/java.base/share/native/libcrexec/image_score.cpp line 44:

> 42:   }
> 43:   _score.foreach([&](const Score& score){
> 44:     fprintf(f, "%s=%f\n", score._name, score._value);

There's no validation that `=` and `\n` are not present in the name so there will probably be problems with parsing

src/java.base/share/native/libcrexec/image_score.hpp line 40:

> 38:   struct Score {
> 39:     const char* _name;
> 40:     double _value;

Since these are public it would be better not to have a leading underscore

src/java.base/share/native/libcrexec/image_score.hpp line 61:

> 59:     const char* name_copy = strdup(name);
> 60:     if (name_copy == nullptr) {
> 61:       return false;

A error message is needed

src/java.base/share/native/libcrexec/image_score.hpp line 64:

> 62:     }
> 63:     return _score.add(Score(name_copy, value));
> 64:   }

This does not adhere to the engine API specification that when a metric name is repeated the old value is replaced

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

PR Review: https://git.openjdk.org/crac/pull/269#pullrequestreview-3344638001
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435757100
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435946887
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435977554
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435991007
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435924045
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435895292
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435900501
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435910912
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435763187
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435813602
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435793224
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435847852
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2435836395
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2436061378
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2436065260
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2436021600
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2436037555

From rvansa at openjdk.org  Tue Oct 21 06:20:37 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 21 Oct 2025 06:20:37 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
 [v4]
In-Reply-To: <SsZu-W3LblSTw0BlbApgM5hEHMRL7X83eHEbJhTioAA=.c59a3b0b-e57c-4fff-bc33-c68b87e8be10@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
 <SsZu-W3LblSTw0BlbApgM5hEHMRL7X83eHEbJhTioAA=.c59a3b0b-e57c-4fff-bc33-c68b87e8be10@github.com>
Message-ID: <niAjrYpsSoeyQcIHZf72uQthfIMFqIZQpVR1DW470tc=.41cd54b0-bef7-4fe0-91b2-d02005d3d556@github.com>

On Thu, 16 Oct 2025 06:09:27 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8369729
>> 
>> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix CI failure

The change looks good, and enabled tests are passing. Thank you!

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/268#pullrequestreview-3358883418

From rvansa at openjdk.org  Tue Oct 21 06:31:41 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 21 Oct 2025 06:31:41 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <b8p_MKs5Jt9Ckd_9oazcd30gA6_2YXPnLUUNhulDh4c=.5c491d27-5d2e-4104-a7ce-c8ccd00c2358@github.com>

On Thu, 16 Oct 2025 12:50:09 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 for PathPatternTest
>
> src/java.base/share/classes/jdk/internal/crac/Score.java line 60:
> 
>> 58:      * recording metadata this is ignored.
>> 59:      * On checkpoint the metrics are not reset; if that is desired invoke {@link #resetAll()}
>> 60:      * manually.
> 
> BTW we should also be documenting this on the engine API level: whether something is reset on checkpoint or not. AFAIR user data is reset, constraints are not, scores ? I haven't checked yet. This can be postponed until we claim the support of repeated checkpoints, I am just saying.

Good point. I think that we're not resetting on the engine level ATM, but we should: otherwise the Java-space `resetAll()` is not effective.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2446849467

From duke at openjdk.org  Tue Oct 21 06:41:43 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Oct 2025 06:41:43 GMT
Subject: [crac] RFR: 8369729: [CRaC] CRaC restore fails with different CPUs
 [v4]
In-Reply-To: <SsZu-W3LblSTw0BlbApgM5hEHMRL7X83eHEbJhTioAA=.c59a3b0b-e57c-4fff-bc33-c68b87e8be10@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
 <SsZu-W3LblSTw0BlbApgM5hEHMRL7X83eHEbJhTioAA=.c59a3b0b-e57c-4fff-bc33-c68b87e8be10@github.com>
Message-ID: <eiQid4xzZtxeNVM3bqyexh0yamsD6Ffr_NRCq03gvHA=.7b5157e8-8ce8-43e6-8b6c-cafcfe2ddc4c@github.com>

On Thu, 16 Oct 2025 06:09:27 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8369729
>> 
>> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix CI failure

@jankratochvil 
Your change (at version 6ef9a1183741ae5844ca7b0ccfc38c2bfd6487e1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/268#issuecomment-3424934426

From rvansa at openjdk.org  Tue Oct 21 06:45:41 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 21 Oct 2025 06:45:41 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <Kf5oOszNgkVZzbCdqhZwxv6jXc26Hb2Eoozs62CszfA=.32dafa0c-ba88-4618-b6e8-7ee7569094d6@github.com>

On Thu, 16 Oct 2025 13:25:18 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 for PathPatternTest
>
> src/hotspot/share/runtime/crac_engine.hpp line 76:
> 
>> 74: 
>> 75:   ApiStatus prepare_image_score_api();
>> 76:   bool set_score(const char* metric, double value);
> 
> Suggestion:
> 
>   bool set_score(const char* metric, double value) const;

While technically it is possible to mark this as `const`, I don't like the message this sends: `_conf` is "owned" by `CRaCEngine`, I consider that an opaque part of its state. But `set_score` mutates the configuration.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2446876797

From rvansa at openjdk.org  Tue Oct 21 06:52:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 21 Oct 2025 06:52:38 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <qNtdhyU_1Iys7BdaD2yg11y1QZCRxQVlPtLgN9wMX-8=.7d6b3c59-f60e-44e8-b182-d6d7044b670f@github.com>

On Thu, 16 Oct 2025 13:43:25 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 for PathPatternTest
>
> src/hotspot/share/runtime/crac.cpp line 733:
> 
>> 731: 
>> 732:   double uptime = TimeHelper::counter_to_millis(os::elapsed_counter());
>> 733:   result = result && _engine->set_score("vm.boot_time", os::javaTimeMillis() - uptime);
> 
> Shouldn't `boot_time()` use `TimeHelper` too?

I had it there, but then I realized that `TimeHelper::counter_to_millis` uses `double` as the return type.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2446894952

From rvansa at openjdk.org  Tue Oct 21 06:56:42 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 21 Oct 2025 06:56:42 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <J7JeKPYi_0HxU5XrjVxSMI_AbJpIodYxu0X6npLXELw=.b07ab555-7803-48f5-96e5-905e1e7bf1b3@github.com>

On Thu, 16 Oct 2025 13:47:02 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 for PathPatternTest
>
> src/hotspot/share/runtime/crac.cpp line 746:
> 
>> 744:   result = result && _engine->set_score("java.cls.sharedUnloadedClasses", shared_unloaded_classes);
>> 745: #endif // INCLUDE_MANAGEMENT
>> 746:   result = result && _engine->set_score("sun.cls.appClassLoadCount", ClassLoader::perf_app_classload_count()->get_value());
> 
> `ClassLoader::perf_app_classload_count()` should return null when `UsePerfData` is false. Worth to check the other counters too.

Good catch, there should be a test variant with `-XX:-UsePerfData`

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2446904947

From tpushkin at openjdk.org  Tue Oct 21 07:18:38 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 21 Oct 2025 07:18:38 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <Kf5oOszNgkVZzbCdqhZwxv6jXc26Hb2Eoozs62CszfA=.32dafa0c-ba88-4618-b6e8-7ee7569094d6@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
 <Kf5oOszNgkVZzbCdqhZwxv6jXc26Hb2Eoozs62CszfA=.32dafa0c-ba88-4618-b6e8-7ee7569094d6@github.com>
Message-ID: <sFCE22mHhnh52PIuG1D_YID981U0gj4Glxvx1Si02WQ=.3f7a7b98-c8d7-4648-93c3-20a8d1a45ffd@github.com>

On Tue, 21 Oct 2025 06:42:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.hpp line 76:
>> 
>>> 74: 
>>> 75:   ApiStatus prepare_image_score_api();
>>> 76:   bool set_score(const char* metric, double value);
>> 
>> Suggestion:
>> 
>>   bool set_score(const char* metric, double value) const;
>
> While technically it is possible to mark this as `const`, I don't like the message this sends: `_conf` is "owned" by `CRaCEngine`, I consider that an opaque part of its state. But `set_score` mutates the configuration.

Agree, there can be two views on whether this should be const or not. But currently we have all other setters as const.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2446982778

From jkratochvil at openjdk.org  Tue Oct 21 09:00:48 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 21 Oct 2025 09:00:48 GMT
Subject: [crac] Integrated: 8369729: [CRaC] CRaC restore fails with different
 CPUs
In-Reply-To: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
References: <Qwxky95QgvVUdPafxGJYDd8khwMGD0X-RkB2s-cx3XE=.2d5842ec-bc50-4471-998f-7d4aa9eaa836@github.com>
Message-ID: <LVivF-oRl8u3Jn-ahnKf7hA26lXjHTlV8HGFp_pCH00=.51db82b2-38f1-4f26-b9fe-6037e7a32da6@github.com>

On Mon, 13 Oct 2025 18:57:43 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369729
> 
> It should be covered by `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` but that needs some fixes (tracked downstream) anyway.

This pull request has now been integrated.

Changeset: e2d4ede7
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/e2d4ede7bdf63bf8b6950ca26a52d3f958322159
Stats:     45 lines in 5 files changed: 39 ins; 2 del; 4 mod

8369729: [CRaC] CRaC restore fails with different CPUs

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Wed Oct 22 11:19:21 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:19:21 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v4]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <ovgS_qKpOA5LjFGv8M6jFeDBp1IMre9UsCpUkyQoW5g=.c3802dde-8dcb-4383-b18e-7b183210bdba@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Update after review

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/523661ab..e3a7d64d

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

  Stats: 305 lines in 17 files changed: 259 ins; 16 del; 30 mod
  Patch: https://git.openjdk.org/crac/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/269/head:pull/269

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

From rvansa at openjdk.org  Wed Oct 22 11:31:51 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:31:51 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v5]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <Pz6QypIntuK_BCEbf1kc2xI0C1F3WpHzCFKH7X1idRQ=.7650c731-afd4-4914-8aba-5697f5f5459f@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Don't record score for the internal global context

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/e3a7d64d..dba1ff1e

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

  Stats: 13 lines in 3 files changed: 7 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/crac/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/269/head:pull/269

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

From rvansa at openjdk.org  Wed Oct 22 11:38:18 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:38:18 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v6]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <xKQp5VqP55p-il6rjpegRB-SEu2I_JJiVqJh1CM1M4o=.51302bd8-f9d7-4c2f-97c1-82017c407f2c@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Add license header

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/dba1ff1e..69cb1585

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

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

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

From rvansa at openjdk.org  Wed Oct 22 11:40:53 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:40:53 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <b_rkYwQ6SUP43mwAEXQg89JpmV7akI64fAjpnnuXhlM=.7a0e67a2-6a52-4164-b01a-bb2639a380da@github.com>

On Thu, 16 Oct 2025 13:35:36 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 for PathPatternTest
>
> src/hotspot/share/runtime/crac.cpp line 715:
> 
>> 713:   ResourceMark rm;
>> 714:   objArrayOop metrics_oops = objArrayOop(JNIHandles::resolve_non_null(metrics));
>> 715:   typeArrayOop values_oops = typeArrayOop(JNIHandles::resolve_non_null(values));
> 
> To be clearer that these are just casts and not construction+copy
> Suggestion:
> 
>   const auto metrics_oops = static_cast<objArrayOop>(JNIHandles::resolve_non_null(metrics));
>   const auto values_oops = static_cast<typeArrayOop>(JNIHandles::resolve_non_null(values));

Using `oop_cast` - there's only one case of such static_cast in the codebase, so I'll go with the (other) standard way.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2451794487

From rvansa at openjdk.org  Wed Oct 22 11:46:44 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:46:44 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <4WvzaIY0TO51h5YxvmoOpoi6FE33UHb7gtTSiScIzHE=.7eb3fc43-4310-4c93-9bbd-8931b3a310bc@github.com>

On Thu, 16 Oct 2025 14:04:46 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 for PathPatternTest
>
> src/java.base/share/native/libcrexec/image_score.cpp line 44:
> 
>> 42:   }
>> 43:   _score.foreach([&](const Score& score){
>> 44:     fprintf(f, "%s=%f\n", score._name, score._value);
> 
> There's no validation that `=` and `\n` are not present in the name so there will probably be problems with parsing

As for `=`, you can easily say that the last `=` is the separator. The `\n` is user shooting himself into foot.
However in general, this format (and its limitations) is engine-specific and there is no way to report the unsuitability. When the score is reported on Java level, the engine is not consulted yet, and later on we could only fail the checkpoint, which seems excessive to me.
If you want, I can truncate the metric name at first `\n` when recording it here.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2451811119

From rvansa at openjdk.org  Wed Oct 22 11:50:51 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:50:51 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
Message-ID: <FFbshMt0U1tt6vt1Cnt13EgVLjsNX4a6xxcaUWMSC8U=.335bfb0f-8f2d-48fa-a389-492a584f9812@github.com>

On Thu, 16 Oct 2025 14:05:26 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 for PathPatternTest
>
> src/java.base/share/native/libcrexec/image_score.hpp line 40:
> 
>> 38:   struct Score {
>> 39:     const char* _name;
>> 40:     double _value;
> 
> Since these are public it would be better not to have a leading underscore

From: https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names

> Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.

No distinction on public/private

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2451820283

From rvansa at openjdk.org  Wed Oct 22 11:53:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 22 Oct 2025 11:53:38 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <Jws9_nd4fYzDfOrhw-WCBe6X509svLGAFKC7xZZhyYA=.df34f911-25b6-45c7-9ff5-f7e7919128e7@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <bljopgGI09xEMl4rkDNqpupiZh9tjUXnmVagqteFN3o=.ad7bf1de-6eeb-4d86-8de4-5d645dd91656@github.com>
 <Jws9_nd4fYzDfOrhw-WCBe6X509svLGAFKC7xZZhyYA=.df34f911-25b6-45c7-9ff5-f7e7919128e7@github.com>
Message-ID: <rbnFB4sFeMBPXVugj-FtBy5PpOIYIgtfefjcmhfWsIc=.f0ba3c92-1134-4d73-bdc4-0921cb0cd8ef@github.com>

On Thu, 16 Oct 2025 08:17:07 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> @TimPushkin I've piggy-backed a fix in `PathPatternTest`, so now this is green. Could you give an ETA on review, please?
>
> @rvansa I'll try to look today, if the time allows; otherwise, I'll look tomorrow.

@TimPushkin I've added the test, and changed the way how the global context size is reported in scores: We have reported the practically constant version of internal global context, not the other (!) global context exposed to the user.

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

PR Comment: https://git.openjdk.org/crac/pull/269#issuecomment-3431981578

From tpushkin at openjdk.org  Thu Oct 23 07:28:57 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 07:28:57 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <4WvzaIY0TO51h5YxvmoOpoi6FE33UHb7gtTSiScIzHE=.7eb3fc43-4310-4c93-9bbd-8931b3a310bc@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
 <4WvzaIY0TO51h5YxvmoOpoi6FE33UHb7gtTSiScIzHE=.7eb3fc43-4310-4c93-9bbd-8931b3a310bc@github.com>
Message-ID: <_uh6yZ9txvnOADeNipdfur7bjMJxlwDTgreLyPMWBjc=.7b49f0ea-b1d0-4fdc-ad5f-12cc10903706@github.com>

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

>> src/java.base/share/native/libcrexec/image_score.cpp line 44:
>> 
>>> 42:   }
>>> 43:   _score.foreach([&](const Score& score){
>>> 44:     fprintf(f, "%s=%f\n", score._name, score._value);
>> 
>> There's no validation that `=` and `\n` are not present in the name so there will probably be problems with parsing
>
> As for `=`, you can easily say that the last `=` is the separator. The `\n` is user shooting himself into foot.
> However in general, this format (and its limitations) is engine-specific and there is no way to report the unsuitability. When the score is reported on Java level, the engine is not consulted yet, and later on we could only fail the checkpoint, which seems excessive to me.
> If you want, I can truncate the metric name at first `\n` when recording it here.

I forgot that the value is not a generic string. With that `=` is indeed not a problem, for `\n` we can truncate with a warning.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454179818

From tpushkin at openjdk.org  Thu Oct 23 07:35:46 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 07:35:46 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v3]
In-Reply-To: <FFbshMt0U1tt6vt1Cnt13EgVLjsNX4a6xxcaUWMSC8U=.335bfb0f-8f2d-48fa-a389-492a584f9812@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M5NoFA3x57QFtTGbh3dR3qhHqPNoq9qP8FPbeSHCZ9M=.40dd3ec9-dc03-48a6-8247-2973a368c65a@github.com>
 <YwqplviRIOFDA9xDmVDIBrD9jR21oB4PmjdJpBlTVxI=.38261341-ca6e-40b8-bc74-cdd7597c67d2@github.com>
 <FFbshMt0U1tt6vt1Cnt13EgVLjsNX4a6xxcaUWMSC8U=.335bfb0f-8f2d-48fa-a389-492a584f9812@github.com>
Message-ID: <u9DsoDNFuGY891WLxcJJYz6sz_K98CSYUkM8bTGHu5w=.d45cfa59-2ca5-41b2-9082-d778c5af51b9@github.com>

On Wed, 22 Oct 2025 11:48:26 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/native/libcrexec/image_score.hpp line 40:
>> 
>>> 38:   struct Score {
>>> 39:     const char* _name;
>>> 40:     double _value;
>> 
>> Since these are public it would be better not to have a leading underscore
>
> From: https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names
> 
>> Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.
> 
> No distinction on public/private

We should "Use public accessor functions for instance variables accessed outside the class" then (the style guide does not differentiate between structs and classes). But ok, let's not complicate the code just to follow the style guide.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454198160

From tpushkin at openjdk.org  Thu Oct 23 08:56:47 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 08:56:47 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v6]
In-Reply-To: <xKQp5VqP55p-il6rjpegRB-SEu2I_JJiVqJh1CM1M4o=.51302bd8-f9d7-4c2f-97c1-82017c407f2c@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <xKQp5VqP55p-il6rjpegRB-SEu2I_JJiVqJh1CM1M4o=.51302bd8-f9d7-4c2f-97c1-82017c407f2c@github.com>
Message-ID: <5W2Cyha0KhS_ddDQC5f3A4MqjzXqsJbp6vOOeWaB16A=.05438b7f-6670-4aa1-82d9-156ee8111b92@github.com>

On Wed, 22 Oct 2025 11:38:18 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add license header

I believe after our internal discussions we've decided to document the format of crexec's score output somewhere?

src/hotspot/share/include/crlib/crlib_image_score.h line 37:

> 35: 
> 36: // API for quantifying image performance. This is a write-only API.
> 37: // The metrics are NOT retained after checkpoint (succesful or not),

Suggestion:

// The metrics are NOT retained after checkpoint (successful or not),

src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 73:

> 71:         // and the context created by jdk.crac.Core (the 'user' global context). We won't record score for
> 72:         // the internal context as if registered here, beforeCheckpoint would be called after Core.Priority.SCORE
> 73:         // and the score would not be recorded.

BTW, it could be useful to count the amount of system-registered resources (recursively, not just the size of the top-level context). Same rationale: more resources => the system is "warmer". But I am not sure the usefulness is great enough to actually implement that.

src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 77:

> 75:             Score score = new Score(name, ctx);
> 76:             synchronized (scores) {
> 77:                 scores.put(name, score);

Maybe add an assert that this returns null (i.e. the name is new) just in case? Or, since there should be only a single score (for the user global context) maybe the map is redundant?

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

PR Review: https://git.openjdk.org/crac/pull/269#pullrequestreview-3368627153
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454211380
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454384337
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454376723

From tpushkin at openjdk.org  Thu Oct 23 08:56:50 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 08:56:50 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v4]
In-Reply-To: <ovgS_qKpOA5LjFGv8M6jFeDBp1IMre9UsCpUkyQoW5g=.c3802dde-8dcb-4383-b18e-7b183210bdba@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <ovgS_qKpOA5LjFGv8M6jFeDBp1IMre9UsCpUkyQoW5g=.c3802dde-8dcb-4383-b18e-7b183210bdba@github.com>
Message-ID: <mKKVW4jd04h6oS7P-U7YDIeDeT1aCdjR2eRXFgnekHM=.719f62a2-3d68-411e-b49c-b387988a4619@github.com>

On Wed, 22 Oct 2025 11:19:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

src/java.base/share/native/libcrexec/crexec.hpp line 45:

> 43:   inline deferred(F f): _f(f) {}
> 44:   inline ~deferred() { _f(); }
> 45: };

Nitpicks: class names are normally capitalized and the constructed should probably be explicit

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

> 126:   const unsigned int hash = string_hash(key) % _capacity;
> 127:   for (size_t i = hash; i < _capacity; i++) {
> 128:     if (strcmp(key, _keys[i]) == 0) {

Since the number of keys can now be less than capacity, i.e. some stored keys may be uninitialized, we should check `_keys[i] != nullptr`

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454237029
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454333630

From tpushkin at openjdk.org  Thu Oct 23 08:56:51 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 08:56:51 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v4]
In-Reply-To: <mKKVW4jd04h6oS7P-U7YDIeDeT1aCdjR2eRXFgnekHM=.719f62a2-3d68-411e-b49c-b387988a4619@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <ovgS_qKpOA5LjFGv8M6jFeDBp1IMre9UsCpUkyQoW5g=.c3802dde-8dcb-4383-b18e-7b183210bdba@github.com>
 <mKKVW4jd04h6oS7P-U7YDIeDeT1aCdjR2eRXFgnekHM=.719f62a2-3d68-411e-b49c-b387988a4619@github.com>
Message-ID: <UHc8nIUAo_n9m9SsX7H0uN4VQAR_HvCuwtOkHmtiqQw=.9dab1b65-413a-4f85-b683-1d4238e1b4cb@github.com>

On Thu, 23 Oct 2025 08:28:18 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/java.base/share/native/libcrexec/hashtable.hpp line 128:
> 
>> 126:   const unsigned int hash = string_hash(key) % _capacity;
>> 127:   for (size_t i = hash; i < _capacity; i++) {
>> 128:     if (strcmp(key, _keys[i]) == 0) {
> 
> Since the number of keys can now be less than capacity, i.e. some stored keys may be uninitialized, we should check `_keys[i] != nullptr`

Actually, I don't remember whether `new[]` default-initializes to null or not. If not, we should do it ourselves.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454337341

From rvansa at openjdk.org  Thu Oct 23 09:51:43 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 23 Oct 2025 09:51:43 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v6]
In-Reply-To: <5W2Cyha0KhS_ddDQC5f3A4MqjzXqsJbp6vOOeWaB16A=.05438b7f-6670-4aa1-82d9-156ee8111b92@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <xKQp5VqP55p-il6rjpegRB-SEu2I_JJiVqJh1CM1M4o=.51302bd8-f9d7-4c2f-97c1-82017c407f2c@github.com>
 <5W2Cyha0KhS_ddDQC5f3A4MqjzXqsJbp6vOOeWaB16A=.05438b7f-6670-4aa1-82d9-156ee8111b92@github.com>
Message-ID: <xnDJyhAIeILEaR0INUDxpx-GLOB9f1iEZ04qhZGYUlY=.4a895669-5a64-4145-ba08-d61f217ae370@github.com>

On Thu, 23 Oct 2025 08:43:25 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add license header
>
> src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 77:
> 
>> 75:             Score score = new Score(name, ctx);
>> 76:             synchronized (scores) {
>> 77:                 scores.put(name, score);
> 
> Maybe add an assert that this returns null (i.e. the name is new) just in case? Or, since there should be only a single score (for the user global context) maybe the map is redundant?

Hmm, I had two Scores but I've removed the 'inner' one in the end. OK, let's keep this in a single variable...

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454552222

From rvansa at openjdk.org  Thu Oct 23 09:54:42 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 23 Oct 2025 09:54:42 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v6]
In-Reply-To: <5W2Cyha0KhS_ddDQC5f3A4MqjzXqsJbp6vOOeWaB16A=.05438b7f-6670-4aa1-82d9-156ee8111b92@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <xKQp5VqP55p-il6rjpegRB-SEu2I_JJiVqJh1CM1M4o=.51302bd8-f9d7-4c2f-97c1-82017c407f2c@github.com>
 <5W2Cyha0KhS_ddDQC5f3A4MqjzXqsJbp6vOOeWaB16A=.05438b7f-6670-4aa1-82d9-156ee8111b92@github.com>
Message-ID: <VboXTd3fEhOKRrMDlRF1klw6rD2zpldz8JTFlpL6hXM=.15baa7c5-01ed-4e53-b38e-2722fd7c5582@github.com>

On Thu, 23 Oct 2025 08:46:28 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add license header
>
> src/java.base/share/classes/jdk/internal/crac/mirror/impl/GlobalContext.java line 73:
> 
>> 71:         // and the context created by jdk.crac.Core (the 'user' global context). We won't record score for
>> 72:         // the internal context as if registered here, beforeCheckpoint would be called after Core.Priority.SCORE
>> 73:         // and the score would not be recorded.
> 
> BTW, it could be useful to count the amount of system-registered resources (recursively, not just the size of the top-level context). Same rationale: more resources => the system is "warmer". But I am not sure the usefulness is great enough to actually implement that.

By system-registered, do you mean `JDKResource` instances? OK, this would be doable (though not recursively, I'd just iterate all Core.Priority contexts).

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2454561419

From rvansa at openjdk.org  Thu Oct 23 12:46:50 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 23 Oct 2025 12:46:50 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v7]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <YLWsQXHkBhpozHSVlnmRaBaCxm440hGUD9W300BXEjA=.d7b76273-b41e-480d-bb11-a6b5c1f7e477@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Add README, truncate metric name, expose jdk.crac.internalResources

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/69cb1585..2ebee46b

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

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

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

From tpushkin at openjdk.org  Thu Oct 23 13:04:00 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 13:04:00 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v7]
In-Reply-To: <YLWsQXHkBhpozHSVlnmRaBaCxm440hGUD9W300BXEjA=.d7b76273-b41e-480d-bb11-a6b5c1f7e477@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <YLWsQXHkBhpozHSVlnmRaBaCxm440hGUD9W300BXEjA=.d7b76273-b41e-480d-bb11-a6b5c1f7e477@github.com>
Message-ID: <vE028G31Mx_mhCiNLr18QU0WfsNXtQcG1wsohEmVqTc=.0a4d3898-0c6d-465e-8a54-38dff6d03e21@github.com>

On Thu, 23 Oct 2025 12:46:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add README, truncate metric name, expose jdk.crac.internalResources

src/java.base/share/classes/jdk/internal/crac/Score.java line 67:

> 65:         int resources = 0;
> 66:         for (var p : Core.Priority.values()) {
> 67:             if (p.getContext() instanceof OrderedContext<?> octx) {

I would prefer a cast just to ensure we don't miss a resource, but for now this should be equivalent

src/java.base/share/native/libcrexec/README.md line 19:

> 17: 
> 18: There is one line per tag created through the `crlib_image_constraints_t` interface, using either the `label:` or `bitmap:` prefix, followed by the tag name and `=`-separated value. In case of bitmap this is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. The string in the example is recorded when JVM runs with:
> 19: 

IIRC, for constraints we forbid `=` and `\n` in both names and values

src/java.base/share/native/libcrexec/README.md line 37:

> 35: ### User Data
> 36: 
> 37: While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.

Suggestion:

While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits>`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.

src/java.base/share/native/libcrexec/README.md line 38:

> 36: 
> 37: While currently not utilized by the JVM, C/R Exec can store custom data in the checkpoint directory. The filename uses the name passed to `crlib_user_data_t`, and the data is encoded as a string of two hexadecimal characters per byte (`<higher-4-bits><lower-4-bits`) in memory order. It is up to JVM to ensure that there would be no conflict with name used by another extension or engine implementation.
> 38: 

I believe this is an extra newline, i.e. there are two newlines at the EOF

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455018904
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455046240
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455049197
PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455051933

From rvansa at openjdk.org  Thu Oct 23 13:13:27 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 23 Oct 2025 13:13:27 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v8]
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <M1TCznVprPYoRybKnB6U6C9SMCyxko6yULdCWGc5S3o=.a23f84f0-faba-4a75-b2ab-c9d1f5a438e4@github.com>

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

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

  Update docs

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

Changes:
  - all: https://git.openjdk.org/crac/pull/269/files
  - new: https://git.openjdk.org/crac/pull/269/files/2ebee46b..cc331fd7

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

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

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

From rvansa at openjdk.org  Thu Oct 23 13:13:30 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 23 Oct 2025 13:13:30 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v7]
In-Reply-To: <vE028G31Mx_mhCiNLr18QU0WfsNXtQcG1wsohEmVqTc=.0a4d3898-0c6d-465e-8a54-38dff6d03e21@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <YLWsQXHkBhpozHSVlnmRaBaCxm440hGUD9W300BXEjA=.d7b76273-b41e-480d-bb11-a6b5c1f7e477@github.com>
 <vE028G31Mx_mhCiNLr18QU0WfsNXtQcG1wsohEmVqTc=.0a4d3898-0c6d-465e-8a54-38dff6d03e21@github.com>
Message-ID: <KWPqie1xkRpDV9o2yAXBMMpqx5dZcl61-7hHf7v_nf8=.050867c3-38d7-4f0d-977a-a613ff95e675@github.com>

On Thu, 23 Oct 2025 12:49:11 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add README, truncate metric name, expose jdk.crac.internalResources
>
> src/java.base/share/classes/jdk/internal/crac/Score.java line 67:
> 
>> 65:         int resources = 0;
>> 66:         for (var p : Core.Priority.values()) {
>> 67:             if (p.getContext() instanceof OrderedContext<?> octx) {
> 
> I would prefer a cast just to ensure we don't miss a resource, but for now this should be equivalent

`Core.Priority.SCORE.getContext()` is not an `OrderedContext`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455084101

From tpushkin at openjdk.org  Thu Oct 23 13:22:55 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 13:22:55 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v7]
In-Reply-To: <KWPqie1xkRpDV9o2yAXBMMpqx5dZcl61-7hHf7v_nf8=.050867c3-38d7-4f0d-977a-a613ff95e675@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <YLWsQXHkBhpozHSVlnmRaBaCxm440hGUD9W300BXEjA=.d7b76273-b41e-480d-bb11-a6b5c1f7e477@github.com>
 <vE028G31Mx_mhCiNLr18QU0WfsNXtQcG1wsohEmVqTc=.0a4d3898-0c6d-465e-8a54-38dff6d03e21@github.com>
 <KWPqie1xkRpDV9o2yAXBMMpqx5dZcl61-7hHf7v_nf8=.050867c3-38d7-4f0d-977a-a613ff95e675@github.com>
Message-ID: <irJmGkC6tzl1jPZV9t0hmAOcXWd1Ogr64ZmpJnwPybA=.5c58ea8f-e114-44a3-841e-ce4e5e915dd1@github.com>

On Thu, 23 Oct 2025 13:09:38 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/crac/Score.java line 67:
>> 
>>> 65:         int resources = 0;
>>> 66:         for (var p : Core.Priority.values()) {
>>> 67:             if (p.getContext() instanceof OrderedContext<?> octx) {
>> 
>> I would prefer a cast just to ensure we don't miss a resource, but for now this should be equivalent
>
> `Core.Priority.SCORE.getContext()` is not an `OrderedContext`.

We could check `p != Core.Priority.SCORE` then. I am suggesting this because it'll make sure we won't miss resources if we add some other type of context in the future. But if you think this is unlikely, I'm OK to leave it as is.

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

PR Review Comment: https://git.openjdk.org/crac/pull/269#discussion_r2455112110

From tpushkin at openjdk.org  Thu Oct 23 13:30:16 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 23 Oct 2025 13:30:16 GMT
Subject: [crac] RFR: 8369566: CRaC: Record metrics during checkpoint [v8]
In-Reply-To: <M1TCznVprPYoRybKnB6U6C9SMCyxko6yULdCWGc5S3o=.a23f84f0-faba-4a75-b2ab-c9d1f5a438e4@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
 <M1TCznVprPYoRybKnB6U6C9SMCyxko6yULdCWGc5S3o=.a23f84f0-faba-4a75-b2ab-c9d1f5a438e4@github.com>
Message-ID: <EnG5b2eQdrbUmVntIWJ53jRCdb4Q9KOhg8Xvn08EGzw=.fa422cc6-0296-4d58-8c52-53e1b770fc18@github.com>

On Thu, 23 Oct 2025 13:13:27 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update docs

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/269#pullrequestreview-3369951463

From rvansa at openjdk.org  Fri Oct 24 07:21:44 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 24 Oct 2025 07:21:44 GMT
Subject: [crac] Integrated: 8369566: CRaC: Record metrics during checkpoint
In-Reply-To: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
References: <2EUFpcVEe07vaAxPCiTwq8vZ2vLt9U-6Yjs_BaWRXRU=.464ed840-2674-4697-a436-0313eca55d51@github.com>
Message-ID: <PlbwWEGReZ_LMJPOeFUZ5_MHPNmzn-ai-iu_MLy2tA4=.7e941b01-5058-43c7-915d-02ee013917dc@github.com>

On Tue, 14 Oct 2025 09:15:52 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> CRaC Engine can support storing additional metadata about the image. This can help the infrastructure to further refine the set of feasible images (constrained by CPU architecture and features) and select the image that is expected to perform best.

This pull request has now been integrated.

Changeset: 1bf79d7f
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/1bf79d7fd7ef7173045f3b880d4f7c9798b9fa9c
Stats:     830 lines in 23 files changed: 753 ins; 24 del; 53 mod

8369566: CRaC: Record metrics during checkpoint

Reviewed-by: tpushkin

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

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

From duke at openjdk.org  Mon Oct 27 20:54:06 2025
From: duke at openjdk.org (Voznia Anton)
Date: Mon, 27 Oct 2025 20:54:06 GMT
Subject: [crac] RFR: 8370483: [CRaC] java/nio/file/spi/SetDefaultProvider.java
 test fails because of incorrect toFile() usage
Message-ID: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>

Solved a regression. I used original approach as it is in the OpenJDK.

`java/nio/file/spi/SetDefaultProvider.java` test is passing.

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

Commit messages:
 - 8370483: [CRaC] java/nio/file/spi/SetDefaultProvider.java test fails because of incorrect toFile() usage in crac

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

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

From tpushkin at openjdk.org  Tue Oct 28 12:22:46 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 28 Oct 2025 12:22:46 GMT
Subject: [crac] RFR: 8370483: [CRaC]
 java/nio/file/spi/SetDefaultProvider.java test fails because of incorrect
 toFile() usage
In-Reply-To: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
References: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
Message-ID: <fpLysr3jcUuvunm49cjQRNaLx6GQV9sGhUvC08u8354=.aac21267-70b3-42f2-a46c-3d184bb47d62@github.com>

On Fri, 24 Oct 2025 11:13:48 GMT, Voznia Anton <duke at openjdk.org> wrote:

> Solved a regression. I used original approach as it is in the OpenJDK.
> 
> `java/nio/file/spi/SetDefaultProvider.java` test is passing.

LGTM, thanks!

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

Marked as reviewed by tpushkin (Committer).

PR Review: https://git.openjdk.org/crac/pull/270#pullrequestreview-3388498334

From duke at openjdk.org  Wed Oct 29 14:33:44 2025
From: duke at openjdk.org (duke)
Date: Wed, 29 Oct 2025 14:33:44 GMT
Subject: [crac] RFR: 8370483: [CRaC]
 java/nio/file/spi/SetDefaultProvider.java test fails because of incorrect
 toFile() usage
In-Reply-To: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
References: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
Message-ID: <RRCq6yWulRNZKbUkP9brwHFKNrPYxPnre82e0O6BA5w=.12891e48-4755-4adc-bf30-c05ad9a8cf16@github.com>

On Fri, 24 Oct 2025 11:13:48 GMT, Voznia Anton <duke at openjdk.org> wrote:

> Solved a regression. I used original approach as it is in the OpenJDK.
> 
> `java/nio/file/spi/SetDefaultProvider.java` test is passing.

@antonvoznia 
Your change (at version 833b30a0ffb62f3af5f20036cc17fa3bffd2c0ad) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/270#issuecomment-3461887423

From duke at openjdk.org  Thu Oct 30 10:22:05 2025
From: duke at openjdk.org (Voznia Anton)
Date: Thu, 30 Oct 2025 10:22:05 GMT
Subject: [crac] Integrated: 8370483: [CRaC]
 java/nio/file/spi/SetDefaultProvider.java test fails because of incorrect
 toFile() usage
In-Reply-To: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
References: <m0e8s4wYqBS7Am1prDgcA0aQ_WTTS3hQ1g1ie8SQ27Y=.9437a3ce-a0dc-4f72-8d7f-fbb99af633db@github.com>
Message-ID: <vj8GEiFqQ7xINBu05Tg2GH-DbaL9oTnIeB02Z4G7pBo=.9fda7a03-463a-4eaa-bc78-7aac01673611@github.com>

On Fri, 24 Oct 2025 11:13:48 GMT, Voznia Anton <duke at openjdk.org> wrote:

> Solved a regression. I used original approach as it is in the OpenJDK.
> 
> `java/nio/file/spi/SetDefaultProvider.java` test is passing.

This pull request has now been integrated.

Changeset: 6cd788fc
Author:    Voznia Anton <avoznia at azul.com>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/6cd788fc3c81d7e8895111f7e113d88cc78d0dcf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370483: [CRaC] java/nio/file/spi/SetDefaultProvider.java test fails because of incorrect toFile() usage

Reviewed-by: tpushkin

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

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

From rvansa at openjdk.org  Thu Oct 30 11:47:21 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 30 Oct 2025 11:47:21 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
Message-ID: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>

When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

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

Commit messages:
 - 8370888: [CRaC] Use better source of random for UUID generation in checkpoint path

Changes: https://git.openjdk.org/crac/pull/271/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370888
  Stats: 64 lines in 6 files changed: 53 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/crac/pull/271.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/271/head:pull/271

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

From tpushkin at openjdk.org  Thu Oct 30 12:05:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 30 Oct 2025 12:05:17 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
Message-ID: <LbzKimhjJnijB9BW_W4Qpzg0qgJWJh1DOip4RxMZOKA=.df8957a1-6053-4586-a1b2-09bcb8e5eba2@github.com>

On Thu, 30 Oct 2025 11:38:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

src/hotspot/os/posix/crac_posix.cpp line 63:

> 61:   for (size_t i = 0; i < length; i += sizeof(int)) {
> 62:     int value = os::next_random(seed);
> 63:     seed = value;

Is there a reason not to use `os::init_random` and `os::random`? It would be just a bit simpler.

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

PR Review Comment: https://git.openjdk.org/crac/pull/271#discussion_r2477845416

From rvansa at openjdk.org  Thu Oct 30 14:17:08 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 30 Oct 2025 14:17:08 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <LbzKimhjJnijB9BW_W4Qpzg0qgJWJh1DOip4RxMZOKA=.df8957a1-6053-4586-a1b2-09bcb8e5eba2@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
 <LbzKimhjJnijB9BW_W4Qpzg0qgJWJh1DOip4RxMZOKA=.df8957a1-6053-4586-a1b2-09bcb8e5eba2@github.com>
Message-ID: <YSy9btbIUC0kIs8_WvzRaJPxSyGCG15a2oejTiQeuBI=.7b2111bb-c560-4dd4-882e-a4beddf555da@github.com>

On Thu, 30 Oct 2025 12:00:41 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.
>
> src/hotspot/os/posix/crac_posix.cpp line 63:
> 
>> 61:   for (size_t i = 0; i < length; i += sizeof(int)) {
>> 62:     int value = os::next_random(seed);
>> 63:     seed = value;
> 
> Is there a reason not to use `os::init_random` and `os::random`? It would be just a bit simpler.

I am not sure why `os::init_random` is not called anywhere AFAICT, but initializing it randomly (with time) could be intrusive; it can be intentionally deterministic based on the seed.

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

PR Review Comment: https://git.openjdk.org/crac/pull/271#discussion_r2478280626

From rvansa at openjdk.org  Thu Oct 30 14:20:01 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 30 Oct 2025 14:20:01 GMT
Subject: [crac] RFR: 8370873: [CRaC] Launcher does not parse CRaC VM options
 from JDK_JAVA_OPTIONS
Message-ID: <hXuce1FDNS8BznMRJSr2Z07_QJevrnBrVyxCmjVZ97g=.9c78361c-bf46-42cf-9fa3-3c0fe88f4ff8@github.com>

Java launcher parses command-line arguments as it needs to perform some operations before the normal parsing in `arguments.cpp`. However the options injected in JDK_JAVA_OPTIONS are ignored in this part (and so does parsing options from files...), leading to problems, e.g. checkpoint of PID 1.

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

Commit messages:
 - 8370873: [CRaC] Launcher does not parse CRaC VM options from JDK_JAVA_OPTIONS

Changes: https://git.openjdk.org/crac/pull/272/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370873
  Stats: 91 lines in 3 files changed: 90 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/crac/pull/272.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/272/head:pull/272

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

From tpushkin at openjdk.org  Thu Oct 30 14:38:29 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 30 Oct 2025 14:38:29 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
Message-ID: <YNuvLDZAOypEXgTjdQODHf3IYdEvRojAPJ8p4u9h0kM=.7ce3d87c-8a5f-420e-90db-c2267f229a29@github.com>

On Thu, 30 Oct 2025 11:38:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

A test failed and it looks like it should rely on random to generate random directory names ? can be related to the change somehow

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

PR Comment: https://git.openjdk.org/crac/pull/271#issuecomment-3468345178

From tpushkin at openjdk.org  Thu Oct 30 14:38:31 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 30 Oct 2025 14:38:31 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <YSy9btbIUC0kIs8_WvzRaJPxSyGCG15a2oejTiQeuBI=.7b2111bb-c560-4dd4-882e-a4beddf555da@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
 <LbzKimhjJnijB9BW_W4Qpzg0qgJWJh1DOip4RxMZOKA=.df8957a1-6053-4586-a1b2-09bcb8e5eba2@github.com>
 <YSy9btbIUC0kIs8_WvzRaJPxSyGCG15a2oejTiQeuBI=.7b2111bb-c560-4dd4-882e-a4beddf555da@github.com>
Message-ID: <xe2LFnD_qsTyvK2TIPqRSVbWjog-6dHYs60uJDQaVHQ=.fc6d3e6a-44ba-47c7-9801-3b1c43dd596f@github.com>

On Thu, 30 Oct 2025 14:13:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/os/posix/crac_posix.cpp line 63:
>> 
>>> 61:   for (size_t i = 0; i < length; i += sizeof(int)) {
>>> 62:     int value = os::next_random(seed);
>>> 63:     seed = value;
>> 
>> Is there a reason not to use `os::init_random` and `os::random`? It would be just a bit simpler.
>
> I am not sure why `os::init_random` is not called anywhere AFAICT, but initializing it randomly (with time) could be intrusive; it can be intentionally deterministic based on the seed.

I was looking at JDK 17 sources accidentally, there it is called in a few places, seemingly with no relations between them. I guess  it's OK since this is random anyway... Ok, let's leave it as is.

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

PR Review Comment: https://git.openjdk.org/crac/pull/271#discussion_r2478353978

From tpushkin at openjdk.org  Thu Oct 30 14:54:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 30 Oct 2025 14:54:54 GMT
Subject: [crac] RFR: 8370873: [CRaC] Launcher does not parse CRaC VM
 options from JDK_JAVA_OPTIONS
In-Reply-To: <hXuce1FDNS8BznMRJSr2Z07_QJevrnBrVyxCmjVZ97g=.9c78361c-bf46-42cf-9fa3-3c0fe88f4ff8@github.com>
References: <hXuce1FDNS8BznMRJSr2Z07_QJevrnBrVyxCmjVZ97g=.9c78361c-bf46-42cf-9fa3-3c0fe88f4ff8@github.com>
Message-ID: <p8bXe6Hj0esgte7CsXd7wBgt3zsTtR56PVPHSgI_R68=.cb1c5e31-d437-48bd-b538-ca808051096b@github.com>

On Thu, 30 Oct 2025 14:11:23 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Java launcher parses command-line arguments as it needs to perform some operations before the normal parsing in `arguments.cpp`. However the options injected in JDK_JAVA_OPTIONS are ignored in this part (and so does parsing options from files...), leading to problems, e.g. checkpoint of PID 1.

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/272#pullrequestreview-3400072603

From rvansa at openjdk.org  Fri Oct 31 09:49:56 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 31 Oct 2025 09:49:56 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <YNuvLDZAOypEXgTjdQODHf3IYdEvRojAPJ8p4u9h0kM=.7ce3d87c-8a5f-420e-90db-c2267f229a29@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
 <YNuvLDZAOypEXgTjdQODHf3IYdEvRojAPJ8p4u9h0kM=.7ce3d87c-8a5f-420e-90db-c2267f229a29@github.com>
Message-ID: <EbL30_TfgTZFzWGpjeUIeE24UrsoP4L6R-ZYyjcPL0Q=.9234319a-eae3-4cdb-a53d-92a3875785ec@github.com>

On Thu, 30 Oct 2025 14:36:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> A test failed and it looks like it should rely on random to generate random directory names ? can be related to the change somehow

Which test should that be? The `java/lang/ProcessBuilder/Basic.java` failure on macos-aarch64 seems to be caused by `TMPDIR` envvar being injected (looking into this, it already failed twice so it does not seem like just a coincidence).

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

PR Comment: https://git.openjdk.org/crac/pull/271#issuecomment-3472177166

From tpushkin at openjdk.org  Fri Oct 31 10:27:49 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 31 Oct 2025 10:27:49 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
Message-ID: <zFhxfT5aE4TPXjfwGb2zhyJWJ9q1Jy1Qn4sfj-LZH7A=.9ab2b3b9-38f9-4023-af64-3c599ffb2e21@github.com>

On Thu, 30 Oct 2025 11:38:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

Yes, I was talking about this test. I didn't dive into it, just saw that the string that triggered the failure contains a seemingly random-generated part and thought it may be influenced by the change somehow

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

PR Comment: https://git.openjdk.org/crac/pull/271#issuecomment-3472367879

From rvansa at openjdk.org  Fri Oct 31 16:07:22 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 31 Oct 2025 16:07:22 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
Message-ID: <0_LfdF7pbM0MTI4kXkRsSMUQoBGpsLBozLjFLcIb2Y0=.5076f85a-dc74-4242-bfac-46cac0a632a2@github.com>

On Thu, 30 Oct 2025 11:38:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

We have the same failure in the unrelated https://github.com/openjdk/crac/pull/272 - I think this must be caused by some recent change in GHA.

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

PR Comment: https://git.openjdk.org/crac/pull/271#issuecomment-3473773511

From tpushkin at openjdk.org  Fri Oct 31 16:35:01 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 31 Oct 2025 16:35:01 GMT
Subject: [crac] RFR: 8370888: [CRaC] Use better source of random for UUID
 generation in checkpoint path
In-Reply-To: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
References: <virV-L9Dm5LdpIDjQRoTuVFunUhrtWtb6b-ZR5zADvY=.1d546d9f-9d8b-44d3-8d9c-bb8cdfd17fb7@github.com>
Message-ID: <qElqViPHbGAkZQDimd4S3nbnBg69ZIlOrCnTV4lvZYg=.d37b21ab-7836-4e5d-831d-0dc2dfad9d05@github.com>

On Thu, 30 Oct 2025 11:38:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When `-XX:CRaCCheckpointTo` contains the `%u` placeholder to generate random UUID, it should use a different source than `os::random()` which provides not-seeded, deterministic values.

Marked as reviewed by tpushkin (Committer).

Yep, it must be https://bugs.openjdk.org/browse/JDK-8368192

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

PR Review: https://git.openjdk.org/crac/pull/271#pullrequestreview-3405113241
PR Comment: https://git.openjdk.org/crac/pull/271#issuecomment-3473893368