From jkratochvil at openjdk.org  Fri May  9 15:29:46 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 9 May 2025 15:29:46 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v9]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <k1CEJ-B02AgNk9V4bOd639V5sJarV-_NI8kQLWo9UhY=.12d3fb3f-4c6d-4fba-ad31-0e1673a49d02@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/03ea8d26..2e7e5baf

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

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

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

From jkratochvil at openjdk.org  Fri May  9 15:29:48 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 9 May 2025 15:29:48 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v8]
In-Reply-To: <UxDHBBENHZVKlSu500z5uShCc0x245nm6zjviQUMa1Y=.fc7d7c77-0371-4ba4-9a30-1824bcc4f2b0@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <BzYkf2GZYlPWCY6IkgD7zzVS7dJ_5a8Vpt3-dsNjzo0=.6179496d-b86c-4d7a-a73d-105fd196c92e@github.com>
 <UxDHBBENHZVKlSu500z5uShCc0x245nm6zjviQUMa1Y=.fc7d7c77-0371-4ba4-9a30-1824bcc4f2b0@github.com>
Message-ID: <g_EvOOKzUoNGPARjc2xjFCslEqRwKTKssJSJp43dPGE=.d8ab07ea-256f-4e49-aa65-3c8ae20db997@github.com>

On Wed, 30 Apr 2025 18:04:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor cpufeatures_check/cpufeatures_load etc.
>
> src/hotspot/share/runtime/crac.cpp line 532:
> 
>> 530:         }
>> 531:         if (!VM_Version::cpu_features_binary_check(present ? &data : nullptr)) {
>> 532:           log_error(crac)("Image %s has incompatible CPU features in its user data %s", CRaCRestoreFrom, engine.cpufeatures_userdata_name);
> 
> I think the user doesn't really need to know the name of the user data in this case, just that the image is incompatible with their CPU. Omitting this would also allow making `cpufeatures_userdata_name` a .cpp static as it was before.

I disagree here. When it is incompatible I want to look at the images with `readelf -n` and to know what to look for. Currently `readelf -n` does not support Warp notes but that should be fixed anyway.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2081927984

From tpushkin at openjdk.org  Fri May  9 15:52:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 9 May 2025 15:52:17 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v8]
In-Reply-To: <g_EvOOKzUoNGPARjc2xjFCslEqRwKTKssJSJp43dPGE=.d8ab07ea-256f-4e49-aa65-3c8ae20db997@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <BzYkf2GZYlPWCY6IkgD7zzVS7dJ_5a8Vpt3-dsNjzo0=.6179496d-b86c-4d7a-a73d-105fd196c92e@github.com>
 <UxDHBBENHZVKlSu500z5uShCc0x245nm6zjviQUMa1Y=.fc7d7c77-0371-4ba4-9a30-1824bcc4f2b0@github.com>
 <g_EvOOKzUoNGPARjc2xjFCslEqRwKTKssJSJp43dPGE=.d8ab07ea-256f-4e49-aa65-3c8ae20db997@github.com>
Message-ID: <uqkDBa1F5g-ZEdujGHGnEcXQ0KW9ml_n7OWMsLaCe7s=.12dbfb25-c6d5-4a1f-83d9-260e62623604@github.com>

On Fri, 9 May 2025 15:25:22 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac.cpp line 532:
>> 
>>> 530:         }
>>> 531:         if (!VM_Version::cpu_features_binary_check(present ? &data : nullptr)) {
>>> 532:           log_error(crac)("Image %s has incompatible CPU features in its user data %s", CRaCRestoreFrom, engine.cpufeatures_userdata_name);
>> 
>> I think the user doesn't really need to know the name of the user data in this case, just that the image is incompatible with their CPU. Omitting this would also allow making `cpufeatures_userdata_name` a .cpp static as it was before.
>
> I disagree here. When it is incompatible I want to look at the images with `readelf -n` and to know what to look for. Currently `readelf -n` does not support Warp notes but that should be fixed anyway.

Agree, it can be useful for engine developers. But I was thinking as an average user which will see this error ? they probably don't know what "user data" is and may get confused thinking something is wrong with their input.

I would suggest making it a debug or verbose log, maybe even unconditional inside the `CracEngine` methods (e.g. "Storing <features_data> as user data <userdata_name>", "Loading user data <userdata_name>") to keep the name private inside the class.

But this is not very important, feel free to skip if doesn't seem as a good idea / feels overcomplicated.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2081966668

From jkratochvil at openjdk.org  Sun May 11 00:16:34 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 11 May 2025 00:16:34 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v10]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <7zcGB_ATdMKNxVmLudJeRPCd1fUm04H8TA3izJHHWt0=.d7bae8d8-b04a-4778-b842-a30043c6ffee@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  Make cpufeatures_userdata_name file local

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/2e7e5baf..4de81c25

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

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

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

From tpushkin at openjdk.org  Mon May 12 12:33:15 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 12 May 2025 12:33:15 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v10]
In-Reply-To: <HqtdaVKYh9OcZmfxYBd4mMEcfdMXX2-kWoQiGqVGHFU=.c123a440-aadf-4be1-bdbf-1efe6eb968a8@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <HqtdaVKYh9OcZmfxYBd4mMEcfdMXX2-kWoQiGqVGHFU=.c123a440-aadf-4be1-bdbf-1efe6eb968a8@github.com>
Message-ID: <WTc78An8mgenA9RwC3laxLIAAojS3jTc5Ne2Xf8esv4=.f6747b67-89f7-494b-8eae-7200c86c79bd@github.com>

On Tue, 29 Apr 2025 08:37:46 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make cpufeatures_userdata_name file local
>
> src/hotspot/share/runtime/crac_engine.cpp line 444:
> 
>> 442:     // s3->set_image_bitmask did handle it already, load_user_data() is too expensive for S3.
>> 443:     return true;
>> 444:   }
> 
> There is no special handling for `s3://` paths in this project

@jankratochvil Looks like you missed this comment

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2084570753

From jkratochvil at openjdk.org  Mon May 12 13:26:19 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 12 May 2025 13:26:19 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v10]
In-Reply-To: <WTc78An8mgenA9RwC3laxLIAAojS3jTc5Ne2Xf8esv4=.f6747b67-89f7-494b-8eae-7200c86c79bd@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <HqtdaVKYh9OcZmfxYBd4mMEcfdMXX2-kWoQiGqVGHFU=.c123a440-aadf-4be1-bdbf-1efe6eb968a8@github.com>
 <WTc78An8mgenA9RwC3laxLIAAojS3jTc5Ne2Xf8esv4=.f6747b67-89f7-494b-8eae-7200c86c79bd@github.com>
Message-ID: <7rrKD8HN1e_E1w4ZXT_QF0U1lajBd9ySGYROgOoauFk=.a0195d94-df7b-45f4-b080-975eefdf07c4@github.com>

On Mon, 12 May 2025 12:30:14 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.cpp line 444:
>> 
>>> 442:     // s3->set_image_bitmask did handle it already, load_user_data() is too expensive for S3.
>>> 443:     return true;
>>> 444:   }
>> 
>> There is no special handling for `s3://` paths in this project
>
> @jankratochvil Looks like you missed this comment

I did not, I am addressing that by:
- https://github.com/openjdk/crac/pull/227/commits/719e7568262f87d7367c6656827ece796e35cadb
- https://github.com/openjdk/crac/pull/227/commits/5ce33434f66913f83b53941b4f9aff8d012f6372

But I need to test it against S3 to finish it and so far I have not managed to setup an S3 test.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2084668228

From jkratochvil at openjdk.org  Tue May 13 14:46:30 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 13 May 2025 14:46:30 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

Jan Kratochvil has updated the pull request incrementally with six additional commits since the last revision:

 - Fix LoggingVMlogOpenTestNegative.java failing in Github CI
 - Remove S3 support
 - Revert "Reimplement S3"
   
   This reverts commit 719e7568262f87d7367c6656827ece796e35cadb.
 - Revert "More S3 fixes but it is untested and for 99.9% not yet working"
   
   This reverts commit 5ce33434f66913f83b53941b4f9aff8d012f6372.
 - More S3 fixes but it is untested and for 99.9% not yet working
 - Reimplement S3

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/4de81c25..e0c32cf7

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

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

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

From jkratochvil at openjdk.org  Tue May 13 14:46:30 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 13 May 2025 14:46:30 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <7rrKD8HN1e_E1w4ZXT_QF0U1lajBd9ySGYROgOoauFk=.a0195d94-df7b-45f4-b080-975eefdf07c4@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <HqtdaVKYh9OcZmfxYBd4mMEcfdMXX2-kWoQiGqVGHFU=.c123a440-aadf-4be1-bdbf-1efe6eb968a8@github.com>
 <WTc78An8mgenA9RwC3laxLIAAojS3jTc5Ne2Xf8esv4=.f6747b67-89f7-494b-8eae-7200c86c79bd@github.com>
 <7rrKD8HN1e_E1w4ZXT_QF0U1lajBd9ySGYROgOoauFk=.a0195d94-df7b-45f4-b080-975eefdf07c4@github.com>
Message-ID: <4S_dkDt3CqEPmbKuBbyR8NpOJcP8i2-EQWYcqbxFBbk=.10c5cc45-74f5-4352-9054-1bf03a551cc3@github.com>

On Mon, 12 May 2025 13:23:10 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> @jankratochvil Looks like you missed this comment
>
> I did not, I am addressing that by:
> - https://github.com/openjdk/crac/pull/227/commits/719e7568262f87d7367c6656827ece796e35cadb
> - https://github.com/openjdk/crac/pull/227/commits/5ce33434f66913f83b53941b4f9aff8d012f6372
> 
> But I need to test it against S3 to finish it and so far I have not managed to setup an S3 test.

So S3 is now removed.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2086465341

From tpushkin at openjdk.org  Tue May 13 19:18:09 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 13 May 2025 19:18:09 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
Message-ID: <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>

On Tue, 13 May 2025 18:01:35 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix LoggingVMlogOpenTestNegative.java failing in Github CI
>>  - Remove S3 support
>>  - Revert "Reimplement S3"
>>    
>>    This reverts commit 719e7568262f87d7367c6656827ece796e35cadb.
>>  - Revert "More S3 fixes but it is untested and for 99.9% not yet working"
>>    
>>    This reverts commit 5ce33434f66913f83b53941b4f9aff8d012f6372.
>>  - More S3 fixes but it is untested and for 99.9% not yet working
>>  - Reimplement S3
>
> src/hotspot/share/runtime/crac.cpp line 133:
> 
>> 131:         "with the selected CRaC engine");
>> 132:       break;
>> 133:   }
> 
> A UX improvement: if the user asks to ignore CPU features or the platform doesn't support them the user should not see warnings/errors about the engine not being able to store them.
> 
> Suggestion:
> 
>   if (!VM_Version::ignore_cpu_features()) {
>     VM_Version::CPUFeaturesBinary data;
>     if (VM_Version::cpu_features_binary(&data)) {
>       switch (_engine->prepare_user_data_api()) {
>         case CracEngine::ApiStatus::OK:
>           if (!_engine->cpufeatures_store(&data)) {
>             return JVM_CHECKPOINT_ERROR;
>           }
>           break;
>         case CracEngine::ApiStatus::ERR:
>           return JVM_CHECKPOINT_ERROR;
>         case CracEngine::ApiStatus::UNSUPPORTED:
>           log_warning(crac)("Cannot store CPUFeatures for checkpoint "
>             "with the selected CRaC engine");
>           break;
>       }
>     }
>   }

I realized the above won't work with the current restore code: if we won't record the features because the user asked us to ignore them but the platform and engine supports them then the restore code will error because the features are not present.

But without that the UX is not great and I don't really understand how `CPUFeatures=ignore` is supposed to work (it is not restore-settable but it is not used on checkpoint).

So maybe it's better to change the restore code to warn instead of erroring when the features are not present (and the warning should ideally be silenceable by `CPUFeatures=ignore` or `IgnoreCPUFeatures`).

> src/java.base/share/native/libcrexec/crexec.cpp line 559:
> 
>> 557:   }
>> 558:   FILE *f = fopen(fname, "w");
>> 559:   if (f == NULL) {
> 
> A nitpick, would also be great to replace in the other places in the file
> Suggestion:
> 
>   if (f == nullptr) {

Would also be great to use `static_cast` and friends instead of C-style casts but since it can be cumbersome to replace sometimes I don't insist

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087398239
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087470455

From tpushkin at openjdk.org  Tue May 13 19:18:09 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 13 May 2025 19:18:09 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
 <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>
Message-ID: <KqGFHtApdHHpLOriKU4JQUFeYaqN_DOL21ASNjGOxfs=.0352d32e-5654-46ff-beca-a961c725ffeb@github.com>

On Tue, 13 May 2025 18:19:50 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac.cpp line 133:
>> 
>>> 131:         "with the selected CRaC engine");
>>> 132:       break;
>>> 133:   }
>> 
>> A UX improvement: if the user asks to ignore CPU features or the platform doesn't support them the user should not see warnings/errors about the engine not being able to store them.
>> 
>> Suggestion:
>> 
>>   if (!VM_Version::ignore_cpu_features()) {
>>     VM_Version::CPUFeaturesBinary data;
>>     if (VM_Version::cpu_features_binary(&data)) {
>>       switch (_engine->prepare_user_data_api()) {
>>         case CracEngine::ApiStatus::OK:
>>           if (!_engine->cpufeatures_store(&data)) {
>>             return JVM_CHECKPOINT_ERROR;
>>           }
>>           break;
>>         case CracEngine::ApiStatus::ERR:
>>           return JVM_CHECKPOINT_ERROR;
>>         case CracEngine::ApiStatus::UNSUPPORTED:
>>           log_warning(crac)("Cannot store CPUFeatures for checkpoint "
>>             "with the selected CRaC engine");
>>           break;
>>       }
>>     }
>>   }
>
> I realized the above won't work with the current restore code: if we won't record the features because the user asked us to ignore them but the platform and engine supports them then the restore code will error because the features are not present.
> 
> But without that the UX is not great and I don't really understand how `CPUFeatures=ignore` is supposed to work (it is not restore-settable but it is not used on checkpoint).
> 
> So maybe it's better to change the restore code to warn instead of erroring when the features are not present (and the warning should ideally be silenceable by `CPUFeatures=ignore` or `IgnoreCPUFeatures`).

This can be postponed until the `CPUFeatures=ignore`/`IgnoreCPUFeatures` cleanup.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087412077

From tpushkin at openjdk.org  Tue May 13 19:18:09 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 13 May 2025 19:18:09 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
Message-ID: <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>

On Tue, 13 May 2025 14:46:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> There was originally a mistake:
>> - restoring JVM did restore the image
>> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
>> 
>> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
>> 
>> This patch changes it to:
>> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
>> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
>> 
>> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.
>
> Jan Kratochvil has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix LoggingVMlogOpenTestNegative.java failing in Github CI
>  - Remove S3 support
>  - Revert "Reimplement S3"
>    
>    This reverts commit 719e7568262f87d7367c6656827ece796e35cadb.
>  - Revert "More S3 fixes but it is untested and for 99.9% not yet working"
>    
>    This reverts commit 5ce33434f66913f83b53941b4f9aff8d012f6372.
>  - More S3 fixes but it is untested and for 99.9% not yet working
>  - Reimplement S3

src/hotspot/cpu/x86/vm_version_x86.cpp line 2618:

> 2616:     warning("-XX:CRaCRestoreFrom is mutually exclusive with -XX:CPUFeatures; specify -XX:CPUFeatures during -XX:CRaCCheckpointTo");
> 2617:     return false;
> 2618:   }

This should be guaranteed by the arguments parsing since `CPUFeatures` is not restore-settable
Suggestion:

  assert(CPUFeatures == nullptr, "This should only be called on restore and CPUFeatures is not restore-settable");

src/hotspot/cpu/x86/vm_version_x86.cpp line 2645:

> 2643:     missing_features(features_missing, glibc_features_missing);
> 2644:     if (!IgnoreCPUFeatures) {
> 2645:       vm_exit_during_initialization();

We can just return false here now

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

> 131:         "with the selected CRaC engine");
> 132:       break;
> 133:   }

A UX improvement: if the user asks to ignore CPU features or the platform doesn't support them the user should not see warnings/errors about the engine not being able to store them.

Suggestion:

  if (!VM_Version::ignore_cpu_features()) {
    VM_Version::CPUFeaturesBinary data;
    if (VM_Version::cpu_features_binary(&data)) {
      switch (_engine->prepare_user_data_api()) {
        case CracEngine::ApiStatus::OK:
          if (!_engine->cpufeatures_store(&data)) {
            return JVM_CHECKPOINT_ERROR;
          }
          break;
        case CracEngine::ApiStatus::ERR:
          return JVM_CHECKPOINT_ERROR;
        case CracEngine::ApiStatus::UNSUPPORTED:
          log_warning(crac)("Cannot store CPUFeatures for checkpoint "
            "with the selected CRaC engine");
          break;
      }
    }
  }

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

> 521:   }
> 522: 
> 523:   if (!VM_Version::ignore_cpu_features()) {

`CPUFeatures` is not restore-settable and `IgnoreCPUFeatures`, rather unexpectedly, does not influence VM_Version::ignore_cpu_features(), so the user will see the warning/errors below even if they knowingly don't want to use CPU features (e.g. their engine doesn't support this).

But AFAIR we decided to postpone the `CPUFeatures=ignore`/`IgnoreCPUFeatures` cleanup and this can be considered a part of that, so I'm ok with leaving this as is for now.

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

> 437: bool CracEngine::cpufeatures_store(const VM_Version::CPUFeaturesBinary *datap) const {
> 438:   log_debug(crac)("cpufeatures_store user data %s to %s...", cpufeatures_userdata_name, CRaCRestoreFrom);
> 439:   return _user_data_api->set_user_data(_conf, cpufeatures_userdata_name, datap, sizeof(*datap));

There's currently no error logging (neither here nor in the caller)
Suggestion:

  const bool ok = _user_data_api->set_user_data(_conf, cpufeatures_userdata_name, datap, sizeof(*datap));
  if (!ok) {
    log_error(crac)("CRaC engine failed to store user data %s", cpufeatures_userdata_name);
  }
  return ok;

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

> 122:   &restore_data_extension.header,
> 123:   &description_extension.header,
> 124:   &user_data_extension.header,

It is better to sort extensions by importance (more important first) for better performance since they are searched linearly by comparing names. Description should be the last one because it is currently only used for printing help and exiting so the speed doesn't matter.

Shouldn't matter much with such small amount of extensions but still.

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

> 546: };
> 547: 
> 548: static bool set_user_data(crlib_conf_t *conf, const char *name, const void *data, size_t size) {

A nitpick: you placed the user-data-related code between `Environment` class and `checkpoint`/`restore` functions which use the class ? it makes the file a bit harder to read. A better place would be `get_restore_data` and `get_extension` functions (the extensions; functions are all placed above `get_extension`, grouped by extension).

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

> 557:   }
> 558:   FILE *f = fopen(fname, "w");
> 559:   if (f == NULL) {

A nitpick, would also be great to replace in the other places in the file
Suggestion:

  if (f == nullptr) {

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

> 576:   }
> 577:   if (fclose(f)) {
> 578:     fprintf(stderr, CREXEC "cannot write to %s: %s\n", fname, strerror(errno));

Suggestion:

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

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087363676
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087359222
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087372826
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087410841
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087298409
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087439546
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087451640
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087467814
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2087468198

From jkratochvil at openjdk.org  Fri May 16 11:09:09 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 11:09:09 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v12]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <sxzFqQr2DV6rbAZzChDXWGQ-FCAlsFPypqvj0TUbnOM=.9b4cca24-666d-4648-8367-ee7ebd5b65e1@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - vm_exit_during_initialization() is no longer needed
 - Eror log failed set_user_data
   
   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/e0c32cf7..345fa973

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

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

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

From jkratochvil at openjdk.org  Fri May 16 11:09:09 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 11:09:09 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
Message-ID: <99Rswc2o3LukM8GfSIGmhOUjCQjkXMDWh0HQ2RhOnTI=.9cf23883-3ff7-412e-855c-7da9b8de11a2@github.com>

On Tue, 13 May 2025 17:51:57 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix LoggingVMlogOpenTestNegative.java failing in Github CI
>>  - Remove S3 support
>>  - Revert "Reimplement S3"
>>    
>>    This reverts commit 719e7568262f87d7367c6656827ece796e35cadb.
>>  - Revert "More S3 fixes but it is untested and for 99.9% not yet working"
>>    
>>    This reverts commit 5ce33434f66913f83b53941b4f9aff8d012f6372.
>>  - More S3 fixes but it is untested and for 99.9% not yet working
>>  - Reimplement S3
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2645:
> 
>> 2643:     missing_features(features_missing, glibc_features_missing);
>> 2644:     if (!IgnoreCPUFeatures) {
>> 2645:       vm_exit_during_initialization();
> 
> We can just return false here now

True, thanks.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2092839530

From jkratochvil at openjdk.org  Fri May 16 11:15:21 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 11:15:21 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v13]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <AknJcvimAjf2WMgUP-j2zaUJmnKJOQmgpFrRcR4uhHo=.0b53f622-0d8d-4cd3-b7c8-06ac111196ea@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - extensions[] performance optimization
 - CPUFeatures is not restore-settable so an assertion is enough
   
   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/345fa973..0111c5f7

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

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

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

From jkratochvil at openjdk.org  Fri May 16 12:18:48 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:18:48 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v14]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <c7x9Nc7lmBvo5NjtEmrGyy799I7aDKw5s_TWSSCp00I=.00bbc83c-8c31-44f4-aed4-139b40326ec5@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  s/NULL/nullptr/

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/0111c5f7..d37b686c

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

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

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

From jkratochvil at openjdk.org  Fri May 16 12:30:00 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:30:00 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v15]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <PLhv8QUPLUX5Ci3UfaBS5I5v2jm938s2E5pascC5sgg=.9fb47c34-7ae6-4520-872b-330354c34944@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - Move the user data functions block
 - Fix write to / close message

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/d37b686c..5a8495cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=227&range=14
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=227&range=13-14

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

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

From jkratochvil at openjdk.org  Fri May 16 12:30:02 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:30:02 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
Message-ID: <Z3RMTQSRKUkr0XOCn1ktH0N87p451FRmrtuej3X0QZs=.f2a330ec-8163-43ed-a1dd-bfd628b211e1@github.com>

On Tue, 13 May 2025 18:28:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix LoggingVMlogOpenTestNegative.java failing in Github CI
>>  - Remove S3 support
>>  - Revert "Reimplement S3"
>>    
>>    This reverts commit 719e7568262f87d7367c6656827ece796e35cadb.
>>  - Revert "More S3 fixes but it is untested and for 99.9% not yet working"
>>    
>>    This reverts commit 5ce33434f66913f83b53941b4f9aff8d012f6372.
>>  - More S3 fixes but it is untested and for 99.9% not yet working
>>  - Reimplement S3
>
> src/hotspot/share/runtime/crac.cpp line 523:
> 
>> 521:   }
>> 522: 
>> 523:   if (!VM_Version::ignore_cpu_features()) {
> 
> `CPUFeatures` is not restore-settable and `IgnoreCPUFeatures`, rather unexpectedly, does not influence VM_Version::ignore_cpu_features(), so the user will see the warning/errors below even if they knowingly don't want to use CPU features (e.g. their engine doesn't support this).
> 
> But AFAIR we decided to postpone the `CPUFeatures=ignore`/`IgnoreCPUFeatures` cleanup and this can be considered a part of that, so I'm ok with leaving this as is for now.

Yes, ZULU-75248.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2092950514

From jkratochvil at openjdk.org  Fri May 16 12:30:03 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:30:03 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
 <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>
Message-ID: <yvXk0BlppKdxkRQF9izw5VtS7B8XEMzfPnZ8O5xiGX8=.96150b00-ace4-4800-a24b-b08e924cca4d@github.com>

On Tue, 13 May 2025 19:12:01 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/java.base/share/native/libcrexec/crexec.cpp line 559:
>> 
>>> 557:   }
>>> 558:   FILE *f = fopen(fname, "w");
>>> 559:   if (f == NULL) {
>> 
>> A nitpick, would also be great to replace in the other places in the file
>> Suggestion:
>> 
>>   if (f == nullptr) {
>
> Would also be great to use `static_cast` and friends instead of C-style casts but since it can be cumbersome to replace sometimes I don't insist

Done the `nullptr`. Personally I do not use C casts in my code at all but by some grepping it looks to me hotspot is mostly using the C costs so I just went with the flow. I do not see casts mentioned in the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md).

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2092944469

From jkratochvil at openjdk.org  Fri May 16 12:43:58 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:43:58 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  Wrap cpufeatures_store() by VM_Version::ignore_cpu_features()

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/5a8495cc..76d3dd42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=227&range=15
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=227&range=14-15

  Stats: 19 lines in 1 file changed: 5 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/crac/pull/227.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/227/head:pull/227

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

From jkratochvil at openjdk.org  Fri May 16 12:43:59 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 May 2025 12:43:59 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v11]
In-Reply-To: <KqGFHtApdHHpLOriKU4JQUFeYaqN_DOL21ASNjGOxfs=.0352d32e-5654-46ff-beca-a961c725ffeb@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <N0RTNvVJKVzw6f84KuLlVHMb0SpgxBPDWL_ouxZo9go=.85616f0c-a281-490f-ad32-619895a517d9@github.com>
 <AHF3RruQFA900h_YIvmy_GQEGlJ1HYlldOM-88SXo5w=.5d51424f-ce90-4e96-b241-0f2280abdc3b@github.com>
 <T9773EDqTqE2ruhyGIB_pdFbOnLSqPOCp93W7474Enw=.bc5cf2b7-47aa-480c-ba69-bbdac1680892@github.com>
 <KqGFHtApdHHpLOriKU4JQUFeYaqN_DOL21ASNjGOxfs=.0352d32e-5654-46ff-beca-a961c725ffeb@github.com>
Message-ID: <nYRfzz-32UwEt9bljCnyF1m2G0p1Ts-H9xFG6MD6FYk=.3eecd24a-56ef-4ab5-815b-4ffd904f68e5@github.com>

On Tue, 13 May 2025 18:29:16 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> I realized the above won't work with the current restore code: if we won't record the features because the user asked us to ignore them but the platform and engine supports them then the restore code will error because the features are not present.
>> 
>> But without that the UX is not great and I don't really understand how `CPUFeatures=ignore` is supposed to work (it is not restore-settable but it is not used on checkpoint).
>> 
>> So maybe it's better to change the restore code to warn instead of erroring when the features are not present (and the warning should ideally be silenceable by `CPUFeatures=ignore` or `IgnoreCPUFeatures`).
>
> This can be postponed until the `CPUFeatures=ignore`/`IgnoreCPUFeatures` cleanup.

I have applied the patch as it makes sense. You are right it cannot be currently used as it depends on `-XX:CPUFeatures=ignore` but that is not restore-settable (only `-XX:+IgnoreCPUFeatures` is but that is a different flag). That should be fixed by ZULU-75248.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2092969611

From tpushkin at openjdk.org  Mon May 19 08:21:23 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 May 2025 08:21:23 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
Message-ID: <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>

On Fri, 16 May 2025 12:43:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> There was originally a mistake:
>> - restoring JVM did restore the image
>> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
>> 
>> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
>> 
>> This patch changes it to:
>> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
>> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
>> 
>> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap cpufeatures_store() by VM_Version::ignore_cpu_features()

The runtime part mostly LGTM given that we've decided to address cleanup of argument parsing and CPU features ignoring in separate patches. The other parts I've reviewed only briefly.

src/hotspot/cpu/x86/vm_version_x86.cpp line 2613:

> 2611: 
> 2612: bool VM_Version::cpu_features_binary_check(const CPUFeaturesBinary *data) {
> 2613:   ResourceMark rm;

Is this `ResourceMark` still needed? I can't see where it might be used.

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

> 121:         VM_Version::CPUFeaturesBinary data;
> 122:         if (!VM_Version::cpu_features_binary(&data)) {
> 123:           // This backend does not use CPUFeatures. That is OK.

In [my suggestion](https://github.com/openjdk/crac/pull/227#discussion_r2087372826) I placed this check before `_engine->prepare_user_data_api()` because if the backend doesn't support CPU features there is no point in querying the engine for its support (and possibly erroring on `CracEngine::ApiStatus::ERR`): we would ask the user to fix the engine issue only for them to find out their backend cannot use this feature anyway.

But since this can be bypassed by ignoring CPU features I'm OK with postponing fixing this together with that.

test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh line 36:

> 34: qemuimgurl=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-41-1.4.x86_64.qcow2
> 35: qemuimgsumurl=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-41-1.4-x86_64-CHECKSUM
> 36: # FIXME: warp+criu need an update for new kernels:

OpenJDK only has CRIU, so it was decided not to have any mentions of other engines and their exclusive features in OpenJDK codebase. Could you please remove the mentions here and in other places?

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

PR Review: https://git.openjdk.org/crac/pull/227#pullrequestreview-2849746499
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095058575
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095066392
PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095116881

From jkratochvil at openjdk.org  Mon May 19 09:27:02 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 09:27:02 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v17]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <K7tnvj3tpXvspsf3iBi5T9I1TpdO_8dEuMVPV1XBUYU=.3d36eea5-5401-4d09-ab3a-090c867ffe88@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  Remove any mentioning of warp

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/76d3dd42..876e0926

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=227&range=16
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=227&range=15-16

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

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

From jkratochvil at openjdk.org  Mon May 19 09:27:03 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 09:27:03 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
 <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
Message-ID: <gi0aGvz3mAHk-r-IE2mq3a0Ga4GNd7mpkDeZ5118Oiw=.7572ad5f-31cb-4b96-977d-def7e9071b39@github.com>

On Mon, 19 May 2025 08:13:19 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap cpufeatures_store() by VM_Version::ignore_cpu_features()
>
> test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh line 36:
> 
>> 34: qemuimgurl=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-41-1.4.x86_64.qcow2
>> 35: qemuimgsumurl=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-41-1.4-x86_64-CHECKSUM
>> 36: # FIXME: warp+criu need an update for new kernels:
> 
> OpenJDK only has CRIU, so it was decided not to have any mentions of other engines and their exclusive features in OpenJDK codebase. Could you please remove the mentions here and in other places?

True, fixed in: 876e0926d7144f0ed04e3f8be24bd95a90866a89

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095265800

From dcherepanov at openjdk.org  Mon May 19 11:21:22 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 19 May 2025 11:21:22 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+4
Message-ID: <uYHp_aX3OKF1PyqbgFeY_NTdFuMDrkzdXRWyAOterGg=.a3e75271-bc93-417c-897a-80c141782f74@github.com>

Clean merge with jdk-25+4

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

Commit messages:
 - Merge jdk:jdk-25+4
 - 8345374: Ubsan: runtime error: division by zero
 - 8346101: [JVMCI] Export jdk.internal.misc to jdk.graal.compiler
 - 8346871: Improve robustness of java/util/zip/EntryCount64k.java test
 - 8302293: jar --create fails with IllegalArgumentException if archive name is shorter than 3 characters
 - 8346831: Remove the extra closing parenthesis in CTW Makefile
 - 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4
 - 8346712: Remove com/sun/net/httpserver/TcpNoDelayNotRequired.java test
 - 8346847: [s390x] minimal build failure
 - 8345757: [ASAN] clang17 report 'dprintf' macro redefined
 - ... and 27 more: https://git.openjdk.org/crac/compare/ca1f5f67...6a4dd9b0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - crac: https://webrevs.openjdk.org/?repo=crac&pr=228&range=00.0
 - jdk:jdk-25+4: https://webrevs.openjdk.org/?repo=crac&pr=228&range=00.1

Changes: https://git.openjdk.org/crac/pull/228/files
  Stats: 6482 lines in 107 files changed: 5673 ins; 422 del; 387 mod
  Patch: https://git.openjdk.org/crac/pull/228.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/228/head:pull/228

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

From rvansa at openjdk.org  Mon May 19 11:43:09 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 19 May 2025 11:43:09 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+4
In-Reply-To: <uYHp_aX3OKF1PyqbgFeY_NTdFuMDrkzdXRWyAOterGg=.a3e75271-bc93-417c-897a-80c141782f74@github.com>
References: <uYHp_aX3OKF1PyqbgFeY_NTdFuMDrkzdXRWyAOterGg=.a3e75271-bc93-417c-897a-80c141782f74@github.com>
Message-ID: <zlVhRxSMZPwUIxe9g5gryTN67V3GD7k7551pnvsvBZo=.dadda5b2-1777-40de-aab2-7457fe5c61ba@github.com>

On Mon, 19 May 2025 11:16:04 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Clean merge with jdk-25+4

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/228#pullrequestreview-2850444714

From dcherepanov at openjdk.org  Mon May 19 11:43:09 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 19 May 2025 11:43:09 GMT
Subject: [crac] Integrated: Merge jdk:jdk-25+4
In-Reply-To: <uYHp_aX3OKF1PyqbgFeY_NTdFuMDrkzdXRWyAOterGg=.a3e75271-bc93-417c-897a-80c141782f74@github.com>
References: <uYHp_aX3OKF1PyqbgFeY_NTdFuMDrkzdXRWyAOterGg=.a3e75271-bc93-417c-897a-80c141782f74@github.com>
Message-ID: <PZ1YEkUDIiVC4gdx3OJYeMF5ZkmDCWGb2n26i5iUTW0=.8b74c422-dde0-4eed-b23d-4286a3b2dfaa@github.com>

On Mon, 19 May 2025 11:16:04 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Clean merge with jdk-25+4

This pull request has now been integrated.

Changeset: ed399705
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/ed3997056b686e6ea136405f3ba51a9be8696ba2
Stats:     6482 lines in 107 files changed: 5673 ins; 422 del; 387 mod

Merge jdk:jdk-25+4

Reviewed-by: rvansa

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

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

From jkratochvil at openjdk.org  Mon May 19 11:52:33 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 11:52:33 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v18]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <mBWxWVhfYDZHX39NfWVO9VwlKs0KBub5sWvVXt_P8e0=.4b23effb-b4da-4d1c-a34e-b88d9c16c970@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  cpu_features_binary_check: remove ResourceMark

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/876e0926..f2e0280f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=227&range=17
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=227&range=16-17

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

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

From jkratochvil at openjdk.org  Mon May 19 11:57:10 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 11:57:10 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
 <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
Message-ID: <1DoOO-Yg2iP-qcejSHPB3gOOyPEwVXyeXdqrKINyRSM=.3323ded3-9bb3-4276-9097-19fca5958d4c@github.com>

On Mon, 19 May 2025 07:43:41 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap cpufeatures_store() by VM_Version::ignore_cpu_features()
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2613:
> 
>> 2611: 
>> 2612: bool VM_Version::cpu_features_binary_check(const CPUFeaturesBinary *data) {
>> 2613:   ResourceMark rm;
> 
> Is this `ResourceMark` still needed? I can't see where it might be used.

I agree, thanks, fixed in: f2e0280f0130732a149a14b76e8e8f26b24f338e

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095540814

From jkratochvil at openjdk.org  Mon May 19 13:07:30 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 13:07:30 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v19]
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <eWh4HYhPcvxrXdIXZIIYc2zlXDYZgGlKKrJKsFnJiR8=.26a31846-d947-4043-a881-4886acea47b0@github.com>

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

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

  Do not call prepare_user_data_api() if no user data is needed

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

Changes:
  - all: https://git.openjdk.org/crac/pull/227/files
  - new: https://git.openjdk.org/crac/pull/227/files/f2e0280f..b7c976c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=227&range=18
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=227&range=17-18

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

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

From jkratochvil at openjdk.org  Mon May 19 13:07:31 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 May 2025 13:07:31 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
 <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
Message-ID: <00NyOK9eXxVqVhjuwhTOqkSRvRHAjFNBXKngQg8nllY=.74cd084f-200f-46cc-b7e1-63a01b88a9bf@github.com>

On Mon, 19 May 2025 07:48:02 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap cpufeatures_store() by VM_Version::ignore_cpu_features()
>
> src/hotspot/share/runtime/crac.cpp line 123:
> 
>> 121:         VM_Version::CPUFeaturesBinary data;
>> 122:         if (!VM_Version::cpu_features_binary(&data)) {
>> 123:           // This backend does not use CPUFeatures. That is OK.
> 
> In [my suggestion](https://github.com/openjdk/crac/pull/227#discussion_r2087372826) I placed this check before `_engine->prepare_user_data_api()` because if the backend doesn't support CPU features there is no point in querying the engine for its support (and possibly erroring on `CracEngine::ApiStatus::ERR`): we would ask the user to fix the engine issue only for them to find out their backend cannot use this feature anyway.
> 
> But since this can be bypassed by ignoring CPU features I'm OK with postponing fixing this together with that.

OK, I have used your code. Do you think about some backend which would not support user data?
b7c976c4a86268ee2455176003d603be6e988955

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095669272

From tpushkin at openjdk.org  Mon May 19 13:32:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 May 2025 13:32:13 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v16]
In-Reply-To: <00NyOK9eXxVqVhjuwhTOqkSRvRHAjFNBXKngQg8nllY=.74cd084f-200f-46cc-b7e1-63a01b88a9bf@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <XriN47Pz0T8A--nJSvl6Us_htC9Yx3MWpyk8nuiXlKQ=.e17f5760-6fef-4896-b5f8-8f95518ec0ff@github.com>
 <aHdzaLE33pPEs_EVoCwKqIXIjlnbaD7k4aRGFmfm8xM=.37edc8c3-c3bf-4c7d-9810-9cdf8d174e6d@github.com>
 <00NyOK9eXxVqVhjuwhTOqkSRvRHAjFNBXKngQg8nllY=.74cd084f-200f-46cc-b7e1-63a01b88a9bf@github.com>
Message-ID: <rFprNfw6_MDsIsbu4njYt22sHlbJbgavgGkBP5Z47e0=.66388162-31fc-49e4-bb43-1cf4682d07ac@github.com>

On Mon, 19 May 2025 13:04:21 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Do you think about some backend which would not support user data?

I assume you are asking about engines, not backends. But no, I don't have anything particular in mind, just theorizing.

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

PR Review Comment: https://git.openjdk.org/crac/pull/227#discussion_r2095719891

From tpushkin at openjdk.org  Mon May 19 14:19:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 May 2025 14:19:11 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM
In-Reply-To: <GHZFTIJvtlENLB914afaN2qbzrbJIG0dvv2sKW_uvvE=.8ea15bfa-2951-40ce-994b-e7f3e9695100@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <367ZGD-U2Rx61ELf96qVcMf3Q1LAz5OERUhPHTWCvJ8=.7c955698-19e2-4769-a883-5bef04056878@github.com>
 <GHZFTIJvtlENLB914afaN2qbzrbJIG0dvv2sKW_uvvE=.8ea15bfa-2951-40ce-994b-e7f3e9695100@github.com>
Message-ID: <2IYwGu0pQZhVHvOjncmtD2VZMgzpWO3b5i14gK2NMxQ=.99f8eb02-2ccf-4e21-93f8-b94d57b67664@github.com>

On Wed, 30 Apr 2025 07:40:02 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> That one failure: `Pre-submit tests - linux-x64 / test - Build / test` = `jdk/crac/fileDescriptors/LoggingVMlogOpenTestNegative.java` will IMO disappear after the change gets accepted. The testcase has been changed so that if you run it from the freshly built JVM it works. But Github IIUC runs the parent JVM pre-built, not from the fresh build: `/home/runner/work/crac/crac/bundles/jdk/jdk-25/bin/java`. Or where is this `bundle` JVM from?
>> 
>> --- this was a wrong idea - the reality is that the failure was due to release vs. debug build as `LogFile` then behaves differently.
>
> @jankratochvil ~The test is failing for me locally, too~ - does it pass on your machine? I had the test fail for something unrelated.
> 
> Could you create JDK issue and refer to that in the title?

@rvansa From my point of view this can be merged (I don't have the rights yet) if the tests pass

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

PR Comment: https://git.openjdk.org/crac/pull/227#issuecomment-2891205729

From tpushkin at openjdk.org  Mon May 19 14:19:10 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 May 2025 14:19:10 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v19]
In-Reply-To: <eWh4HYhPcvxrXdIXZIIYc2zlXDYZgGlKKrJKsFnJiR8=.26a31846-d947-4043-a881-4886acea47b0@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <eWh4HYhPcvxrXdIXZIIYc2zlXDYZgGlKKrJKsFnJiR8=.26a31846-d947-4043-a881-4886acea47b0@github.com>
Message-ID: <MLoSqbcEdJO_IWSgvq1QYI0YaszDT2RidQi7-dsn8Ow=.fe9ee034-41c6-4347-822e-b813906896d2@github.com>

On Mon, 19 May 2025 13:07:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> There was originally a mistake:
>> - restoring JVM did restore the image
>> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
>> 
>> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
>> 
>> This patch changes it to:
>> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
>> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
>> 
>> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not call prepare_user_data_api() if no user data is needed

Marked as reviewed by tpushkin (Author).

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

PR Review: https://git.openjdk.org/crac/pull/227#pullrequestreview-2850933816

From tpushkin at openjdk.org  Tue May 20 07:46:08 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 20 May 2025 07:46:08 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail
In-Reply-To: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
Message-ID: <foNkMMifOy844OjxbE_RBqz5qNke6NBd0jVLd_z7oAc=.ebe85f8b-78eb-4b59-a198-efe1a890fef9@github.com>

On Wed, 16 Apr 2025 13:13:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Fixes the failing test, for simplicity pretending that both `jdk.crac` and `jdk.management/jdk.crac.management` were added in JDK 24 and before that there was no CRaC in the JDK. Otherwise we would need to retroactively generate symbols for JDKs 17?23 which is a decent amount of work (there are no public CRaC builds for some of these versions).
> 
> JDK 24 symbols were updated this way:
> 1. Create a custom build from the last OpenJDK 24 CRaC commit 884d0746b168550f13bdc687b1d96d468aec4411 (the last commit before JDK 25 was merged).
> 2. Update the symbols from that build using `make/scripts/generate-symbol-data.sh`.
> 3. Manually remove the CRaC methods removed in d64fb30c0874d93c986ad04ac3995a727b7a1ac8 from the symbols.
> 
> Also adds the since-checking tests to CI.
> 
> I initially wanted to also add a since-checking test for `jdk.crac` module but `SinceChecker` seems to have a bug which makes the test fail with ?module: jdk.crac: `@since` version is 24 but the element exists before JDK 10?. I believe this is a `SinceChecker` bug because the same happens for other modules added after JDK 9 without a legacy preview, e.g. `jdk.graal.compiler`.

Still active. I need to check if [JDK-8345212](https://bugs.openjdk.org/browse/JDK-8345212) will work as expected and then we'll decide whether we want to go that way or the way this PR was originally done.

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

PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2893302353

From duke at openjdk.org  Tue May 20 09:10:11 2025
From: duke at openjdk.org (duke)
Date: Tue, 20 May 2025 09:10:11 GMT
Subject: [crac] RFR: 8355974: [CRaC] Move CPUFeatures verification to the
 parent process of JVM [v19]
In-Reply-To: <eWh4HYhPcvxrXdIXZIIYc2zlXDYZgGlKKrJKsFnJiR8=.26a31846-d947-4043-a881-4886acea47b0@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
 <eWh4HYhPcvxrXdIXZIIYc2zlXDYZgGlKKrJKsFnJiR8=.26a31846-d947-4043-a881-4886acea47b0@github.com>
Message-ID: <tDaDvozt7L1-eZBgr3IJC4rmKvXLuD3grDHsNtGYjUs=.a456600a-c691-4e1e-b585-2ea61b3eb59d@github.com>

On Mon, 19 May 2025 13:07:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> There was originally a mistake:
>> - restoring JVM did restore the image
>> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
>> 
>> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
>> 
>> This patch changes it to:
>> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
>> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
>> 
>> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not call prepare_user_data_api() if no user data is needed

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

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

PR Comment: https://git.openjdk.org/crac/pull/227#issuecomment-2893574093

From jkratochvil at openjdk.org  Tue May 20 09:28:21 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 20 May 2025 09:28:21 GMT
Subject: [crac] Integrated: 8355974: [CRaC] Move CPUFeatures verification to
 the parent process of JVM
In-Reply-To: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
References: <zmwd6cxJwhRkKCbvyMWrQy-FU-XTgtAFmceyCfqVLd0=.3af81391-3eaf-4af8-95a9-e1a916ccce0b@github.com>
Message-ID: <QBUZbtQEfIuHvXuJl8CVxtEkUETRl9K8sWI-bciE50E=.ad5ea255-b1ae-4c45-a31c-1103600dddd7@github.com>

On Sun, 27 Apr 2025 15:18:17 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> There was originally a mistake:
> - restoring JVM did restore the image
> - the restored JVM started checking whether CPU Features of the new host >= CPU Features of the checkpoint host
> 
> That is difficult as glibc is already configured (IFUNC) in the image for the checkpoint host and calling any such glibc functions in the restored image will crash (as the advanced instructions from misconfigured IFUNC are not available). Some glibc functions had to be reimplemented in a dummy way inside JVM due to this misdesign.
> 
> This patch changes it to:
> - restoring JVM checks `cpufeatures` user data in the image against current CPU Features
> - the restored JVM is started only if the CPU Features are satisfied, restored JVM no longer has to verify anything
> 
> The patch is a bit of a kitchen sink, there are various improvements of the CPU Features code.

This pull request has now been integrated.

Changeset: 2eb2197b
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/2eb2197b667aafeab9e22742a4712e8245dd1f2c
Stats:     1098 lines in 22 files changed: 893 ins; 105 del; 100 mod

8355974: [CRaC] Move CPUFeatures verification to the parent process of JVM

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Fri May 23 11:10:47 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 23 May 2025 11:10:47 GMT
Subject: [crac] RFR: 8357641: [CRaC] Support PID change during
 checkpoint-restore
Message-ID: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>

Adds updates of cached PID on restore.

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

Commit messages:
 - JVM/JDK code using getpid() and gettid() returns stale values on GLIBC < 2.25
 - Reset PID in ProcessHandleImpl on restore
 - Replace getpid() use with syscall in os::current_process_id()

Changes: https://git.openjdk.org/crac/pull/229/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=229&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357641
  Stats: 96 lines in 15 files changed: 87 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/crac/pull/229.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/229/head:pull/229

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

From martin.welgemoed at commercetools.com  Fri May 23 11:26:32 2025
From: martin.welgemoed at commercetools.com (Martin Welgemoed)
Date: Fri, 23 May 2025 13:26:32 +0200
Subject: Compatible vdso's size is bigger than reserved buf
Message-ID: <CAB0hby+hYvAjSSJK53DmPYVMDMRfnyKBO1s8F=vTCxb-hBb2iw@mail.gmail.com>

Hello everyone,

CRaC has been working quite well for us. Recently we upgraded
Kubernetes in GKE to 1.31 (kernel 6.6.72+) and since then CRaC
snapshots fail to restore with "Error: Compatible vdso's size is
bigger than reserved buf".

This is specifically for the 32bit compat VDSO. Running strace
confirms that the kernel now has it at 3 pages (12kb) in size.

arch_prctl(ARCH_MAP_VDSO_32, 0x7ffd1d983000) = 12288

In COMPAT_VDSO_BUF_SZ CRaC only allocates 2 pages for it
https://github.com/CRaC/criu/blob/e7aefe4f9e499597ddf484394d29fc4752b674dd/criu/vdso.c#L482

I'm somewhat surprised by it being 3 pages, because on my own local
machine (6.14.5-arch1-1) it is still 8kb:

arch_prctl(ARCH_MAP_VDSO_32, 0x789ea0a00000) = 8192

I think this is possibly a GKE configuration thing for its kernel build.

Does anyone else have experience with this or a solution for it? I
think increasing the COMPAT_VDSO_BUF_SZ could solve it but I am not
experienced enough with CRIU or the VDSO to fully judge the
implications of this.

Kind regards,

-- 
Martin Welgemoed
Scala Engineer

martin.welgemoed at commercetools.com
T. +49 (89) 99 82 996-0
commercetools B.V. | Prins Bernhardplein 200 | 1097 JB Amsterdam

-- 





commercetools B.V.
Prins Bernhardplein 200, 1097 JB Amsterdam | 
Netherlands
www.commercetools.com <http://www.commercetools.com/>


-- 





commercetools GmbH
Adams-Lehmann-Str. 44?| 80797 Munich?| Germany
Register: HRB 161496?| Local Court at Munich
Managing Directors Dirk H?rig?
| Denis Werner

 
<https://elevate.commercetools.com//?utm_source=Email&utm_medium=Outreach&utm_content=Elevate-2025&utm_campaign=events-global>

From tpushkin at openjdk.org  Fri May 23 11:28:27 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 23 May 2025 11:28:27 GMT
Subject: [crac] RFR: 8357645: [CRaC] Use Alpine-based images when executing
 tests on musl
Message-ID: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>

Makes CRaC tests which use containers use Alpine-based images when run on a musl-based system.

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

Commit messages:
 - Use alpine-based images when executing on musl

Changes: https://git.openjdk.org/crac/pull/230/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357645
  Stats: 19 lines in 4 files changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/crac/pull/230.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/230/head:pull/230

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

From rvansa at openjdk.org  Fri May 23 14:55:05 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 23 May 2025 14:55:05 GMT
Subject: [crac] RFR: 8357641: [CRaC] Support PID change during
 checkpoint-restore
In-Reply-To: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
References: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
Message-ID: <RdNEnememqy2vDMqfY-l0TkxGfiQnEuAznINB1_xPvk=.567b027f-3647-4f1f-b7ff-8d7c56425345@github.com>

On Fri, 23 May 2025 11:03:37 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds updates of cached PID on restore.

LGTM, thanks!

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/229#pullrequestreview-2864708273

From duke at openjdk.org  Fri May 23 20:47:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 23 May 2025 20:47:09 GMT
Subject: [crac] RFR: 8357641: [CRaC] Support PID change during
 checkpoint-restore
In-Reply-To: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
References: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
Message-ID: <5kiP_SqEHlPxKPiW6nIWoFkojKY1waTUdMMi9e81YbA=.29246d70-2f54-40e7-945d-db2ae8723e4e@github.com>

On Fri, 23 May 2025 11:03:37 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds updates of cached PID on restore.

@TimPushkin 
Your change (at version d6a0cacc427e484d3ff11aea81c97c62c124db01) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/229#issuecomment-2905771699

From duke at openjdk.org  Fri May 23 20:48:23 2025
From: duke at openjdk.org (duke)
Date: Fri, 23 May 2025 20:48:23 GMT
Subject: [crac] RFR: 8357645: [CRaC] Use Alpine-based images when executing
 tests on musl
In-Reply-To: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
References: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
Message-ID: <kDTmxmOqrD1IfZ8kc7mCbm20gHHUuZud7R8ntiPIENU=.58d49d80-4298-4340-a65f-51a18023d21d@github.com>

On Fri, 23 May 2025 11:22:04 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes CRaC tests which use containers use Alpine-based images when run on a musl-based system.

@TimPushkin 
Your change (at version dc9a3acd79e971c16f9c17a1c8ab32cce46234da) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/230#issuecomment-2905773444

From tpushkin at openjdk.org  Mon May 26 12:08:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 26 May 2025 12:08:11 GMT
Subject: [crac] Integrated: 8357641: [CRaC] Support PID change during
 checkpoint-restore
In-Reply-To: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
References: <reAfyJOAVmGMvsgRyhWpCalaUlVtBlpqFDK_BbDgFSA=.2db92a82-7bf0-4011-920a-ba1a0ed64115@github.com>
Message-ID: <Sf-6uJxRr9f8mh6ahO9OsTtB48HqNi3yCZDMvsA_w1M=.52a81078-80ee-4403-aacf-d16d9f39e012@github.com>

On Fri, 23 May 2025 11:03:37 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds updates of cached PID on restore.

This pull request has now been integrated.

Changeset: d5191e55
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/d5191e554d53b34c336e77765600bf5100f68396
Stats:     96 lines in 15 files changed: 87 ins; 2 del; 7 mod

8357641: [CRaC] Support PID change during checkpoint-restore

Co-authored-by: Radim Vansa <rvansa at openjdk.org>
Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Mon May 26 12:10:15 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 26 May 2025 12:10:15 GMT
Subject: [crac] RFR: 8357645: [CRaC] Use Alpine-based images when executing
 tests on musl
In-Reply-To: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
References: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
Message-ID: <v3uNTG31rRoYbejytO1CdoN1RvedEhbDFOi4_Oxoom4=.74c25ea5-d1cf-4da9-a759-e7d838160bb0@github.com>

On Fri, 23 May 2025 11:22:04 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes CRaC tests which use containers use Alpine-based images when run on a musl-based system.

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/230#pullrequestreview-2868220101

From tpushkin at openjdk.org  Mon May 26 12:10:15 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 26 May 2025 12:10:15 GMT
Subject: [crac] Integrated: 8357645: [CRaC] Use Alpine-based images when
 executing tests on musl
In-Reply-To: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
References: <Soc6omRFtlbhphKdwpunUfKpW3UMjoCWKZHUthTNF_4=.eff32286-4ff0-4e3f-b63b-4e51c6aca2fd@github.com>
Message-ID: <3SPfvm3gWFM0MSu7n6Yyw3DWgouMEBjt8SGpHg0HLLE=.a81c94b3-7550-4e05-a0d4-9544924fdcf5@github.com>

On Fri, 23 May 2025 11:22:04 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes CRaC tests which use containers use Alpine-based images when run on a musl-based system.

This pull request has now been integrated.

Changeset: 906ea072
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/906ea072f47b46d8b7d3b8e511633df6302bca72
Stats:     19 lines in 4 files changed: 14 ins; 0 del; 5 mod

8357645: [CRaC] Use Alpine-based images when executing tests on musl

Co-authored-by: Radim Vansa <rvansa at openjdk.org>
Reviewed-by: rvansa

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

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

From dcherepanov at openjdk.org  Mon May 26 22:51:55 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 26 May 2025 22:51:55 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+10
Message-ID: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>

This PR includes merges for tags between `jdk-25+5` and `jdk-25+10`, attaching output of  `--diff-merges=remerge` for each merge

<details>

<summary>jdk-25+5</summary>


commit 5ae68607f0b679587a60a1aab8b2aadb4105bbb7
Merge: ed3997056b6 2e00816ac30
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Mon May 19 22:35:02 2025 +0400

    Merge with jdk-25+5


</details>

<details>

<summary>jdk-25+6</summary>


commit cc975a31216702e48256ad35e96957c978190027
Merge: 5ae68607f0b 9c430c92257
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Mon May 26 20:44:57 2025 +0400

    Merge with jdk-25+6

diff --git a/src/hotspot/share/compiler/compileLog.cpp b/src/hotspot/share/compiler/compileLog.cpp
index 4c8165fc7bd..f183d628d45 100644
--- a/src/hotspot/share/compiler/compileLog.cpp
+++ b/src/hotspot/share/compiler/compileLog.cpp
@@ -340,7 +340,7 @@ void CompileLog::finish_log_on_checkpoint(outputStream* file) {
       // print/print_cr may need to allocate large stack buffer to format
       // strings, here we use snprintf() and print_raw() instead.
       file->print_raw("<compilation_log thread='");
-      jio_snprintf(buf, buflen, UINTX_FORMAT, log->thread_id());
+      jio_snprintf(buf, buflen, "%zu", log->thread_id());
       file->print_raw(buf);
       file->print_raw_cr("'>");
 
diff --git a/src/hotspot/share/gc/parallel/psParallelCompact.cpp b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/parallel/psParallelCompact.cpp
index 00bb365dffd..438b6b90740 100644
--- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
+++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
@@ -1,10 +1,6 @@
 /*
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
- * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
-=======
  * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
+ * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
diff --git a/src/hotspot/share/gc/serial/defNewGeneration.cpp b/src/hotspot/share/gc/serial/defNewGeneration.cpp
remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/serial/defNewGeneration.cpp
index 1151a9847b5..bbb0a64ad5c 100644
--- a/src/hotspot/share/gc/serial/defNewGeneration.cpp
+++ b/src/hotspot/share/gc/serial/defNewGeneration.cpp
@@ -1,10 +1,6 @@
 /*
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
- * Copyright (c) 2001, 2024, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
-=======
  * Copyright (c) 2001, 2025, Oracle and/or its affiliates. All rights reserved.
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
+ * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
remerge CONFLICT (content): Merge conflict in src/hotspot/share/runtime/arguments.cpp
index 36913cea320..a185c895ec4 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -1,10 +1,6 @@
 /*
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
- * Copyright (c) 1997, 2024, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2017, 2024, Azul Systems, Inc. All rights reserved.
-=======
  * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
+ * Copyright (c) 2017, 2024, Azul Systems, Inc. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
diff --git a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
remerge CONFLICT (content): Merge conflict in src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
index 58772e8328e..e3a1b749388 100644
--- a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
+++ b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
@@ -34,14 +34,8 @@
 
 import java.io.File;
 import java.io.IOException;
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
 import java.nio.file.Files;
 import java.nio.file.Path;
-import java.security.AccessControlContext;
-import java.security.AccessController;
-=======
-import java.nio.file.Path;
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
 import java.time.Duration;
 import java.time.Instant;
 import java.util.ArrayList;
@@ -53,11 +47,7 @@
 import java.util.Set;
 import java.util.Timer;
 import java.util.TimerTask;
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
-import java.util.concurrent.CopyOnWriteArrayList;
 import java.util.stream.Collectors;
-=======
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
 
 import jdk.internal.crac.Core;
 import jdk.internal.crac.JDKResource;
@@ -133,15 +123,12 @@ public void afterRestore(Context<? extends Resource> context) throws Exception {
             synchronized (PlatformRecorder.this) {
                 futureRecordings.forEach(r -> {
                     recordings.add(r);
-                    WriteableUserPath destination = r.getDestination();
-                    // The backup recording has to be moved before creating WriteableUserPath
+                    WriteablePath destination = r.getDestination();
+                    // The backup recording has to be moved before creating WriteablePath
                     // (and touching the recording output file)
                     try {
-                        destination.doPrivilegedIO(() -> {
-                            File destFile = destination.getReal().toFile();
-                            if (!destFile.exists()) {
-                                return null;
-                            }
+                        File destFile = destination.getReal().toFile();
+                        if (destFile.exists()) {
                             Path backup = null;
                             for (int i = 0; backup == null && i < MAX_BACKUPS; ++i) {
                                 String name = destFile.getName();
@@ -161,15 +148,14 @@ public void afterRestore(Context<? extends Resource> context) throws Exception {
                                 Files.move(destFile.toPath(), backup);
                                 Logger.log(JFR, INFO, "Backed up " + destFile + " to " + backup);
                             }
-                            return null;
-                        });
+                        }
                     } catch (IOException e) {
                         Logger.log(JFR, ERROR, "Cannot backup previous recording: " + e);
                     }
                     try {
-                        // We need to invoke WritableUserPath after restore to create the dump file.
-                        // Since we're creating another WritableUserPath we can use the original specification
-                        r.setDestination(new WriteableUserPath(destination.getPotentiallyMaliciousOriginal()));
+                        // We need to invoke WriteablePath after restore to create the dump file.
+                        // Since we're creating another WriteablePath we can use the original specification
+                        r.setDestination(new WriteablePath(destination.getPath()));
                     } catch (IOException e) {
                         Logger.log(JFR, ERROR, "Cannot reset recording destination: " + e);
                     }
@@ -188,33 +174,11 @@ public PlatformRecorder() throws Exception {
         JDKEvents.initialize();
         Logger.log(JFR_SYSTEM, INFO, "Registered JDK events");
         startDiskMonitor();
-<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
-        shutdownHook = SecuritySupport.createThreadWitNoPermissions("JFR Shutdown Hook", new ShutdownHook(this));
-        SecuritySupport.setUncaughtExceptionHandler(shutdownHook, new ShutdownHook.ExceptionHandler());
-        SecuritySupport.registerShutdownHook(shutdownHook);
-
-        Core.Priority.JFR.getContext().register(resource);
-    }
-
-
-    private static Timer createTimer() {
-        try {
-            List<Timer> result = new CopyOnWriteArrayList<>();
-            Thread t = SecuritySupport.createThreadWitNoPermissions("Permissionless thread", ()-> {
-                result.add(new Timer("JFR Recording Scheduler", true));
-            });
-            JVM.exclude(t);
-            t.start();
-            t.join();
-            return result.getFirst();
-        } catch (InterruptedException e) {
-            throw new IllegalStateException("Not able to create timer task. " + e.getMessage(), e);
-        }
-=======
         shutdownHook = new ShutdownHook(this);
         shutdownHook.setUncaughtExceptionHandler(new ShutdownHook.ExceptionHandler());
         Runtime.getRuntime().addShutdownHook(shutdownHook);
->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
+
+        Core.Priority.JFR.getContext().register(resource);
     }
 
     public synchronized PlatformRecording newRecording(Map<String, String> settings) {
diff --git a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java
index def8f757615..91430369ed2 100644
--- a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java
+++ b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java
@@ -827,7 +827,7 @@ private static List<RepositoryChunk> reduceFromEnd(Long maxSize, List<Repository
         return result;
     }
 
-    SafePath getDumpDirectory() {
+    Path getDumpDirectory() {
         return dumpDirectory;
     }
 


</details>

Merge with jdk-25+6 requires additional changes
- use `%zu` after [JDK-8346990](https://bugs.openjdk.org/browse/JDK-8346990)
- adjust JFR code after [JDK-8347287](https://bugs.openjdk.org/browse/JDK-8347287) refactored helper classes

<details>

<summary>jdk-25+7</summary>


commit b150e5dae99fdb451b00344ea53dde0f3139a3cf
Merge: cc975a31216 8cf07358397
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Mon May 26 22:28:44 2025 +0400

    Merge with jdk-25+7

diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp
remerge CONFLICT (content): Merge conflict in src/hotspot/os/linux/os_linux.cpp
index 5ddb60173e4..08386bf941a 100644
--- a/src/hotspot/os/linux/os_linux.cpp
+++ b/src/hotspot/os/linux/os_linux.cpp
@@ -24,11 +24,7 @@
  *
  */
 
-<<<<<<< cc975a31216 (Merge with jdk-25+6)
-// no precompiled headers
 #include "classfile/classLoader.hpp"
-=======
->>>>>>> 8cf07358397 (8348102: java/net/httpclient/HttpClientSNITest.java fails intermittently)
 #include "classfile/vmSymbols.hpp"
 #include "code/vtableStubs.hpp"
 #include "compiler/compileBroker.hpp"
diff --git a/src/hotspot/os/windows/crac_windows.cpp b/src/hotspot/os/windows/crac_windows.cpp
index e5c69ec440b..8fff5135bf4 100644
--- a/src/hotspot/os/windows/crac_windows.cpp
+++ b/src/hotspot/os/windows/crac_windows.cpp
@@ -21,8 +21,6 @@
  * questions.
  */
 
-#include "precompiled.hpp"
-
 #include "jvm.h"
 #include "runtime/crac_structs.hpp"
 
diff --git a/src/hotspot/share/gc/g1/g1CollectedHeap.cpp b/src/hotspot/share/gc/g1/g1CollectedHeap.cpp
remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/g1/g1CollectedHeap.cpp
index b9d443c32c9..c0e2f158284 100644
--- a/src/hotspot/share/gc/g1/g1CollectedHeap.cpp
+++ b/src/hotspot/share/gc/g1/g1CollectedHeap.cpp
@@ -1,10 +1,6 @@
 /*
-<<<<<<< cc975a31216 (Merge with jdk-25+6)
- * Copyright (c) 2001, 2024, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
-=======
  * Copyright (c) 2001, 2025, Oracle and/or its affiliates. All rights reserved.
->>>>>>> 8cf07358397 (8348102: java/net/httpclient/HttpClientSNITest.java fails intermittently)
+ * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp
index 974ae74fdc7..02a70bfd2a3 100644
--- a/src/hotspot/share/gc/z/zPageAllocator.cpp
+++ b/src/hotspot/share/gc/z/zPageAllocator.cpp
@@ -1059,7 +1059,7 @@ void ZPageAllocator::uncommit_unused_memory() {
   } while (flushed > 0);
   if (uncommitted > 0) {
     EventZUncommit event;
-    log_info(gc, heap)("Uncommitted (cleanup): " SIZE_FORMAT "M(%.0f%%)",
+    log_info(gc, heap)("Uncommitted (cleanup): %zuM(%.0f%%)",
       uncommitted / M, percent_of(uncommitted, ZHeap::heap()->max_capacity()));
     event.commit(uncommitted);
   }
diff --git a/src/hotspot/share/runtime/crac.cpp b/src/hotspot/share/runtime/crac.cpp
index 85610dde1e6..5580538bbcc 100644
--- a/src/hotspot/share/runtime/crac.cpp
+++ b/src/hotspot/share/runtime/crac.cpp
@@ -21,8 +21,6 @@
  * questions.
  */
 
-#include "precompiled.hpp"
-
 #include "classfile/classLoader.hpp"
 #include "jfr/jfr.hpp"
 #include "jvm.h"
diff --git a/src/hotspot/share/runtime/crac_engine.cpp b/src/hotspot/share/runtime/crac_engine.cpp
index b5ae02bbf7a..40f981c3f03 100644
--- a/src/hotspot/share/runtime/crac_engine.cpp
+++ b/src/hotspot/share/runtime/crac_engine.cpp
@@ -21,8 +21,6 @@
  * questions.
  */
 
-#include "precompiled.hpp"
-
 #include "crlib/crlib.h"
 #include "crlib/crlib_restore_data.h"
 #include "logging/log.hpp"
diff --git a/test/lib/jdk/test/lib/crac/CracTest.java b/test/lib/jdk/test/lib/crac/CracTest.java
index 8ccea9cea67..383d50a2566 100644
--- a/test/lib/jdk/test/lib/crac/CracTest.java
+++ b/test/lib/jdk/test/lib/crac/CracTest.java
@@ -56,6 +56,7 @@ class ArgsHolder {
     /**
      * Main method for orchestrating the test. This should be called directly by JTReg.
      */
+    @SuppressWarnings("unchecked")
     static void main(String[] args) throws Exception {
         String testClassName;
         if (args.length == 0 || !ArgsHolder.RUN_TEST.equals(args[0])) {
@@ -99,6 +100,7 @@ static void main(String[] args) throws Exception {
      * @param args Arguments received in the main method.
      * @throws Exception
      */
+    @SuppressWarnings("unchecked")
     static void run(Class<? extends CracTest> testClass, String[] args) throws Exception {
         assertNotNull(args);
         ArgsHolder.testClass = testClass;


</details>

Merge with jdk-25+7 requires additional changes
- avoid explicit `#include "precompiled.hpp"` after [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909)
- use `%zu` after [JDK-8347731](https://bugs.openjdk.org/browse/JDK-8347731)
- suppress unchecked warning in `CracTest.java` after [JDK-8347840](https://bugs.openjdk.org/browse/JDK-8347840) enabled warnings in build scripts 

<details>

<summary>jdk-25+8</summary>


commit c1da8a1879af8360e5ced3a5011a4de17604bae2
Merge: b150e5dae99 d985b31cbb5
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Tue May 27 01:33:18 2025 +0400

    Merge with jdk-25+8

diff --git a/src/java.base/share/classes/java/security/SecureRandom.java b/src/java.base/share/classes/java/security/SecureRandom.java
remerge CONFLICT (content): Merge conflict in src/java.base/share/classes/java/security/SecureRandom.java
index 170b21b603f..c5104d883f8 100644
--- a/src/java.base/share/classes/java/security/SecureRandom.java
+++ b/src/java.base/share/classes/java/security/SecureRandom.java
@@ -214,14 +214,11 @@ public class SecureRandom extends java.util.Random {
      * "{@docRoot}/../specs/security/standard-names.html#securerandom-number-generation-algorithms">
      * Java Security Standard Algorithm Names Specification</a>
      * for information about standard RNG algorithm names.
-<<<<<<< b150e5dae99 (Merge with jdk-25+7)
      *
      * @crac Instances created by this constructor are automatically reseeded
      * after restore from a checkpoint.
      * See {@link sun.security.provider.SecureRandom} for details.
-=======
      * @spec security/standard-names.html Java Security Standard Algorithm Names
->>>>>>> d985b31cbb5 (8342096: Popup menus that request focus are not shown on Linux with Wayland)
      */
     public SecureRandom() {
         /*


</details>

<details>

<summary>jdk-25+9</summary>


commit 203c311bb3aaa8bcd44b3b6b6849ced3a4846c11
Merge: c1da8a1879a 30f71622a1c
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Tue May 27 01:33:25 2025 +0400

    Merge with jdk-25+9


</details>

<details>

<summary>jdk-25+10</summary>


commit 2aac32e50e809f6cdd4dfeb1b1ef438e6afc4668 (HEAD -> merge-jdk, dmitry-crac/merge-jdk)
Merge: 203c311bb3a a637ccf2fea
Author: Dmitry Cherepanov <dcherepanov at azul.com>
Date:   Tue May 27 01:34:26 2025 +0400

    Merge with jdk-25+10

diff --git a/.jcheck/conf b/.jcheck/conf
remerge CONFLICT (content): Merge conflict in .jcheck/conf
index aaca839a59d..25bd8dd0b94 100644
--- a/.jcheck/conf
+++ b/.jcheck/conf
@@ -13,31 +13,3 @@ ignore=duke
 [census]
 version=0
 domain=openjdk.org
-<<<<<<< 203c311bb3a (Merge with jdk-25+9)
-=======
-
-[checks "whitespace"]
-files=.*.cpp|.*.hpp|.*.c|.*.h|.*.java|.*.cc|.*.hh|.*.m|.*.mm|.*.S|.*.md|.*.properties|.*.gmk|.*.m4|.*.ac|Makefile
-ignore-tabs=.*.gmk|Makefile
-
-[checks "merge"]
-message=Merge
-
-[checks "reviewers"]
-reviewers=1
-ignore=duke
-
-[checks "committer"]
-role=committer
-
-[checks "issues"]
-pattern=^([124-8][0-9]{6}): (\S.*)$
-
-[checks "problemlists"]
-dirs=test/jdk|test/langtools|test/lib-test|test/hotspot/jtreg|test/jaxp
-
-[checks "copyright"]
-files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar).*
-oracle_locator=.*Copyright (c)(.*)Oracle and/or its affiliates. All rights reserved.
-oracle_validator=.*Copyright (c) (\d{4})(?:, (\d{4}))?, Oracle and/or its affiliates. All rights reserved.
->>>>>>> a637ccf2fea (8349851: RISC-V: Call VM leaf can use movptr2)
diff --git a/make/modules/java.base/Launcher.gmk b/make/modules/java.base/Launcher.gmk
remerge CONFLICT (content): Merge conflict in make/modules/java.base/Launcher.gmk
index 5d4f2da27b1..d3baea141ab 100644
--- a/make/modules/java.base/Launcher.gmk
+++ b/make/modules/java.base/Launcher.gmk
@@ -104,7 +104,6 @@ ifeq ($(call isTargetOsType, unix), true)
 endif
 
 ################################################################################
-<<<<<<< 203c311bb3a (Merge with jdk-25+9)
 
 ifeq ($(OPENJDK_TARGET_OS), linux)
   $(eval $(call SetupJdkExecutable, BUILD_CRIUENGINE, \
@@ -162,5 +161,3 @@ $(CRIU_CRAC_BIN) : $(USE_CRIU_CRAC)
 endif
 
 ################################################################################
-=======
->>>>>>> a637ccf2fea (8349851: RISC-V: Call VM leaf can use movptr2)
diff --git a/make/modules/java.base/Lib.gmk b/make/modules/java.base/Lib.gmk
remerge CONFLICT (content): Merge conflict in make/modules/java.base/Lib.gmk
index 32638089365..d964c56871f 100644
--- a/make/modules/java.base/Lib.gmk
+++ b/make/modules/java.base/Lib.gmk
@@ -201,7 +201,6 @@ ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2)
 endif
 
 ################################################################################
-<<<<<<< 203c311bb3a (Merge with jdk-25+9)
 # Build checkpoint/restore exec library
 ################################################################################
 
@@ -215,5 +214,3 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBCREXEC, \
     LDFLAGS := $(LDFLAGS_JDKLIB), \
 ))
 TARGETS += $(BUILD_LIBCREXEC)
-=======
->>>>>>> a637ccf2fea (8349851: RISC-V: Call VM leaf can use movptr2)


</details>

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

Commit messages:
 - Merge with jdk-25+10
 - 8349851: RISC-V: Call VM leaf can use movptr2
 - 8349787: java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly without libVThreadPinner.so
 - 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni
 - 6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063
 - 8349934: Wrong file regex for copyright header format check in .jcheck/conf
 - 8349571: Remove JavaThreadFactory interface from SA
 - 8349684: Remove SA core file tests from problem list for macosx-x64
 - 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition
 - 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore
 - ... and 537 more: https://git.openjdk.org/crac/compare/ed399705...2aac32e5

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - crac: https://webrevs.openjdk.org/?repo=crac&pr=231&range=00.0
 - jdk:jdk-25+10: https://webrevs.openjdk.org/?repo=crac&pr=231&range=00.1

Changes: https://git.openjdk.org/crac/pull/231/files
  Stats: 205176 lines in 4867 files changed: 97022 ins; 87259 del; 20895 mod
  Patch: https://git.openjdk.org/crac/pull/231.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/231/head:pull/231

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

From rvansa at openjdk.org  Tue May 27 06:36:12 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 06:36:12 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+10
In-Reply-To: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
References: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
Message-ID: <WPIhDCWZIHdBkdvzB-iLcMlIz75BT6pfdwsHsLPCeU4=.9641ef81-ec63-49a6-a381-bf868861c8da@github.com>

On Mon, 26 May 2025 22:46:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR includes merges for tags between `jdk-25+5` and `jdk-25+10`, attaching output of  `--diff-merges=remerge` for each merge
> 
> <details>
> 
> <summary>jdk-25+5</summary>
> 
> 
> commit 5ae68607f0b679587a60a1aab8b2aadb4105bbb7
> Merge: ed3997056b6 2e00816ac30
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 19 22:35:02 2025 +0400
> 
>     Merge with jdk-25+5
> 
> 
> </details>
> 
> <details>
> 
> <summary>jdk-25+6</summary>
> 
> 
> commit cc975a31216702e48256ad35e96957c978190027
> Merge: 5ae68607f0b 9c430c92257
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 26 20:44:57 2025 +0400
> 
>     Merge with jdk-25+6
> 
> diff --git a/src/hotspot/share/compiler/compileLog.cpp b/src/hotspot/share/compiler/compileLog.cpp
> index 4c8165fc7bd..f183d628d45 100644
> --- a/src/hotspot/share/compiler/compileLog.cpp
> +++ b/src/hotspot/share/compiler/compileLog.cpp
> @@ -340,7 +340,7 @@ void CompileLog::finish_log_on_checkpoint(outputStream* file) {
>        // print/print_cr may need to allocate large stack buffer to format
>        // strings, here we use snprintf() and print_raw() instead.
>        file->print_raw("<compilation_log thread='");
> -      jio_snprintf(buf, buflen, UINTX_FORMAT, log->thread_id());
> +      jio_snprintf(buf, buflen, "%zu", log->thread_id());
>        file->print_raw(buf);
>        file->print_raw_cr("'>");
>  
> diff --git a/src/hotspot/share/gc/parallel/psParallelCompact.cpp b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/parallel/psParallelCompact.cpp
> index 00bb365dffd..438b6b90740 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,10 +1,6 @@
>  /*
> -<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
> - * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
> + * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> diff --git a/src/hotspot/share/gc/serial/defNewGeneration.cpp b/src/hotspot/share/gc/serial/defNewGeneration.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/serial/defNewGeneration.cpp...

The remerge diff looks correct, thanks!
I hope that the `SIZE_FORMAT`/`UINTX` -> `%zu` won't cause differences with CRaC applied into older versions. TBH in my code I've always (I think) used `%zu`, and it seems that C++14 (hence C99) is available since 16, so we shouldn't have an issue with that.

Could you check whether there are any uses of these formatters and SecurityManager (which is a pattern that is removed by these changes) throughout CRaC codebase?

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

PR Review: https://git.openjdk.org/crac/pull/231#pullrequestreview-2869771177

From rvansa at azul.com  Tue May 27 07:24:41 2025
From: rvansa at azul.com (Radim Vansa)
Date: Tue, 27 May 2025 09:24:41 +0200
Subject: Compatible vdso's size is bigger than reserved buf
In-Reply-To: <CAB0hby+hYvAjSSJK53DmPYVMDMRfnyKBO1s8F=vTCxb-hBb2iw@mail.gmail.com>
References: <CAB0hby+hYvAjSSJK53DmPYVMDMRfnyKBO1s8F=vTCxb-hBb2iw@mail.gmail.com>
Message-ID: <07e15877-1573-4f21-960a-0d95ec9cec51@azul.com>

Hello Martin,

thanks for bringing this to our attention. It looks like upstream CRIU 
has it already patched to 4 pages [1], but we haven't cherry-picked that 
change yet. Regarding VDSO, we shall also cherry-pick the fixes for 
kernel 6.13+ which introduces the [vvar_clock] VMA [2][3].

Could you send a PR with the cherry pick to https://github.com/crac/criu ?

Thanks!

Radim

[1] 
https://github.com/checkpoint-restore/criu/commit/70a9cd6fbf46d96b7bd49f38f3e013bd892a990e
[2] 
https://github.com/checkpoint-restore/criu/commit/058572e91dea1d8ac9c345e69e08a58e8abfacbb
[3] 
https://github.com/checkpoint-restore/criu/commit/720bf67e065525133f4b0209baa7142192fbb667

On 23. 05. 25 13:26, Martin Welgemoed wrote:
> Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hello everyone,
>
> CRaC has been working quite well for us. Recently we upgraded
> Kubernetes in GKE to 1.31 (kernel 6.6.72+) and since then CRaC
> snapshots fail to restore with "Error: Compatible vdso's size is
> bigger than reserved buf".
>
> This is specifically for the 32bit compat VDSO. Running strace
> confirms that the kernel now has it at 3 pages (12kb) in size.
>
> arch_prctl(ARCH_MAP_VDSO_32, 0x7ffd1d983000) = 12288
>
> In COMPAT_VDSO_BUF_SZ CRaC only allocates 2 pages for it
> https://github.com/CRaC/criu/blob/e7aefe4f9e499597ddf484394d29fc4752b674dd/criu/vdso.c#L482
>
> I'm somewhat surprised by it being 3 pages, because on my own local
> machine (6.14.5-arch1-1) it is still 8kb:
>
> arch_prctl(ARCH_MAP_VDSO_32, 0x789ea0a00000) = 8192
>
> I think this is possibly a GKE configuration thing for its kernel build.
>
> Does anyone else have experience with this or a solution for it? I
> think increasing the COMPAT_VDSO_BUF_SZ could solve it but I am not
> experienced enough with CRIU or the VDSO to fully judge the
> implications of this.
>
> Kind regards,
>
> --
> Martin Welgemoed
> Scala Engineer
>
> martin.welgemoed at commercetools.com
> T. +49 (89) 99 82 996-0
> commercetools B.V. | Prins Bernhardplein 200 | 1097 JB Amsterdam
>
> --
>
>
>
>
>
> commercetools B.V.
> Prins Bernhardplein 200, 1097 JB Amsterdam |
> Netherlands
> www.commercetools.com <http://www.commercetools.com/>
>
>
> --
>
>
>
>
>
> commercetools GmbH
> Adams-Lehmann-Str. 44 | 80797 Munich | Germany
> Register: HRB 161496 | Local Court at Munich
> Managing Directors Dirk H?rig
> | Denis Werner
>
>
> <https://elevate.commercetools.com//?utm_source=Email&utm_medium=Outreach&utm_content=Elevate-2025&utm_campaign=events-global>

From dcherepanov at openjdk.org  Tue May 27 07:56:12 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 27 May 2025 07:56:12 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+10
In-Reply-To: <WPIhDCWZIHdBkdvzB-iLcMlIz75BT6pfdwsHsLPCeU4=.9641ef81-ec63-49a6-a381-bf868861c8da@github.com>
References: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
 <WPIhDCWZIHdBkdvzB-iLcMlIz75BT6pfdwsHsLPCeU4=.9641ef81-ec63-49a6-a381-bf868861c8da@github.com>
Message-ID: <0yvntTc7E-ZZZvDFyrb8w2pP-hekROKj3tO_UALSxrw=.34efb783-2667-4056-ad3f-27cdce459c43@github.com>

On Tue, 27 May 2025 06:33:16 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> The remerge diff looks correct, thanks! I hope that the `SIZE_FORMAT`/`UINTX` -> `%zu` won't cause differences with CRaC applied into older versions. TBH in my code I've always (I think) used `%zu`, and it seems that C++14 (hence C99) is available since 16, so we shouldn't have an issue with that.
> 
> Could you check whether there are any uses of these formatters and SecurityManager (which is a pattern that is removed by these changes) throughout CRaC codebase?

Thanks for the review!

I checked CRaC source code and didn't find any uses of helper classes removed as a part of the merge.

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

PR Comment: https://git.openjdk.org/crac/pull/231#issuecomment-2911535937

From rvansa at openjdk.org  Tue May 27 10:56:13 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 10:56:13 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+10
In-Reply-To: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
References: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
Message-ID: <uNCK5l7Vbb8bWLZvneCgNFnXJNn6uB0jBv-XEKsBybQ=.bde7335c-64d9-447d-9bd2-5073d8ca2d96@github.com>

On Mon, 26 May 2025 22:46:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR includes merges for tags between `jdk-25+5` and `jdk-25+10`, attaching output of  `--diff-merges=remerge` for each merge
> 
> <details>
> 
> <summary>jdk-25+5</summary>
> 
> 
> commit 5ae68607f0b679587a60a1aab8b2aadb4105bbb7
> Merge: ed3997056b6 2e00816ac30
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 19 22:35:02 2025 +0400
> 
>     Merge with jdk-25+5
> 
> 
> </details>
> 
> <details>
> 
> <summary>jdk-25+6</summary>
> 
> 
> commit cc975a31216702e48256ad35e96957c978190027
> Merge: 5ae68607f0b 9c430c92257
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 26 20:44:57 2025 +0400
> 
>     Merge with jdk-25+6
> 
> diff --git a/src/hotspot/share/compiler/compileLog.cpp b/src/hotspot/share/compiler/compileLog.cpp
> index 4c8165fc7bd..f183d628d45 100644
> --- a/src/hotspot/share/compiler/compileLog.cpp
> +++ b/src/hotspot/share/compiler/compileLog.cpp
> @@ -340,7 +340,7 @@ void CompileLog::finish_log_on_checkpoint(outputStream* file) {
>        // print/print_cr may need to allocate large stack buffer to format
>        // strings, here we use snprintf() and print_raw() instead.
>        file->print_raw("<compilation_log thread='");
> -      jio_snprintf(buf, buflen, UINTX_FORMAT, log->thread_id());
> +      jio_snprintf(buf, buflen, "%zu", log->thread_id());
>        file->print_raw(buf);
>        file->print_raw_cr("'>");
>  
> diff --git a/src/hotspot/share/gc/parallel/psParallelCompact.cpp b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/parallel/psParallelCompact.cpp
> index 00bb365dffd..438b6b90740 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,10 +1,6 @@
>  /*
> -<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
> - * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
> + * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> diff --git a/src/hotspot/share/gc/serial/defNewGeneration.cpp b/src/hotspot/share/gc/serial/defNewGeneration.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/serial/defNewGeneration.cpp...

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/231#pullrequestreview-2870598076

From duke at openjdk.org  Tue May 27 11:05:12 2025
From: duke at openjdk.org (duke)
Date: Tue, 27 May 2025 11:05:12 GMT
Subject: [crac] RFR: Merge jdk:jdk-25+10
In-Reply-To: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
References: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
Message-ID: <s5uBn8FKZxpDNbJJ5b-oKph0kGrzTnVtEZxSKMcqhkc=.dda154f8-4710-470e-88c5-e8158295b5a0@github.com>

On Mon, 26 May 2025 22:46:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR includes merges for tags between `jdk-25+5` and `jdk-25+10`, attaching output of  `--diff-merges=remerge` for each merge
> 
> <details>
> 
> <summary>jdk-25+5</summary>
> 
> 
> commit 5ae68607f0b679587a60a1aab8b2aadb4105bbb7
> Merge: ed3997056b6 2e00816ac30
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 19 22:35:02 2025 +0400
> 
>     Merge with jdk-25+5
> 
> 
> </details>
> 
> <details>
> 
> <summary>jdk-25+6</summary>
> 
> 
> commit cc975a31216702e48256ad35e96957c978190027
> Merge: 5ae68607f0b 9c430c92257
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 26 20:44:57 2025 +0400
> 
>     Merge with jdk-25+6
> 
> diff --git a/src/hotspot/share/compiler/compileLog.cpp b/src/hotspot/share/compiler/compileLog.cpp
> index 4c8165fc7bd..f183d628d45 100644
> --- a/src/hotspot/share/compiler/compileLog.cpp
> +++ b/src/hotspot/share/compiler/compileLog.cpp
> @@ -340,7 +340,7 @@ void CompileLog::finish_log_on_checkpoint(outputStream* file) {
>        // print/print_cr may need to allocate large stack buffer to format
>        // strings, here we use snprintf() and print_raw() instead.
>        file->print_raw("<compilation_log thread='");
> -      jio_snprintf(buf, buflen, UINTX_FORMAT, log->thread_id());
> +      jio_snprintf(buf, buflen, "%zu", log->thread_id());
>        file->print_raw(buf);
>        file->print_raw_cr("'>");
>  
> diff --git a/src/hotspot/share/gc/parallel/psParallelCompact.cpp b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/parallel/psParallelCompact.cpp
> index 00bb365dffd..438b6b90740 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,10 +1,6 @@
>  /*
> -<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
> - * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
> + * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> diff --git a/src/hotspot/share/gc/serial/defNewGeneration.cpp b/src/hotspot/share/gc/serial/defNewGeneration.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/serial/defNewGeneration.cpp...

@dimitryc 
Your change (at version 2aac32e50e809f6cdd4dfeb1b1ef438e6afc4668) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/231#issuecomment-2912102029

From dcherepanov at openjdk.org  Tue May 27 11:21:18 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 27 May 2025 11:21:18 GMT
Subject: [crac] Integrated: Merge jdk:jdk-25+10
In-Reply-To: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
References: <YnhpYRCHWEjlbClzNqizWKVRA61HHzLPvRG8fCo-u2o=.82291a92-37e4-494b-8cfc-eab0865b7c72@github.com>
Message-ID: <ZCq2WL9VCGoAKctVSjSnePcsFjz2g1l8JI0PhqJX2uc=.b6a3c850-ab9e-41c6-b2ce-311a9d172874@github.com>

On Mon, 26 May 2025 22:46:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> This PR includes merges for tags between `jdk-25+5` and `jdk-25+10`, attaching output of  `--diff-merges=remerge` for each merge
> 
> <details>
> 
> <summary>jdk-25+5</summary>
> 
> 
> commit 5ae68607f0b679587a60a1aab8b2aadb4105bbb7
> Merge: ed3997056b6 2e00816ac30
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 19 22:35:02 2025 +0400
> 
>     Merge with jdk-25+5
> 
> 
> </details>
> 
> <details>
> 
> <summary>jdk-25+6</summary>
> 
> 
> commit cc975a31216702e48256ad35e96957c978190027
> Merge: 5ae68607f0b 9c430c92257
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Mon May 26 20:44:57 2025 +0400
> 
>     Merge with jdk-25+6
> 
> diff --git a/src/hotspot/share/compiler/compileLog.cpp b/src/hotspot/share/compiler/compileLog.cpp
> index 4c8165fc7bd..f183d628d45 100644
> --- a/src/hotspot/share/compiler/compileLog.cpp
> +++ b/src/hotspot/share/compiler/compileLog.cpp
> @@ -340,7 +340,7 @@ void CompileLog::finish_log_on_checkpoint(outputStream* file) {
>        // print/print_cr may need to allocate large stack buffer to format
>        // strings, here we use snprintf() and print_raw() instead.
>        file->print_raw("<compilation_log thread='");
> -      jio_snprintf(buf, buflen, UINTX_FORMAT, log->thread_id());
> +      jio_snprintf(buf, buflen, "%zu", log->thread_id());
>        file->print_raw(buf);
>        file->print_raw_cr("'>");
>  
> diff --git a/src/hotspot/share/gc/parallel/psParallelCompact.cpp b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/parallel/psParallelCompact.cpp
> index 00bb365dffd..438b6b90740 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,10 +1,6 @@
>  /*
> -<<<<<<< 5ae68607f0b (Merge with jdk-25+5)
> - * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 9c430c92257 (8336920: ArithmeticException in javax.sound.sampled.AudioInputStream)
> + * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> diff --git a/src/hotspot/share/gc/serial/defNewGeneration.cpp b/src/hotspot/share/gc/serial/defNewGeneration.cpp
> remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/serial/defNewGeneration.cpp...

This pull request has now been integrated.

Changeset: 9279f066
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/9279f066049c38935bd65c52e114dd1ba5308403
Stats:     205176 lines in 4867 files changed: 97022 ins; 87259 del; 20895 mod

Merge jdk:jdk-25+10

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Tue May 27 12:37:42 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 27 May 2025 12:37:42 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail [v2]
In-Reply-To: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
Message-ID: <X2sQkd7AT730ios8GEwLjZEugastlcvBSIbpmLyqFmo=.501b3e15-b594-4c95-9730-78fe680761da@github.com>

> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
> 
> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
> 
> Also adds the since-checking tests to CI.

Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Fix since checker test with ignoreSince
 - Revert "Fix since checker test"
   
   This reverts commit a4fb97899d8c6d8667b355feac655dcd6875780b.
 - Merge remote-tracking branch 'openjdk-crac/crac' into since-checker
 - Fix since checker test

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

Changes:
  - all: https://git.openjdk.org/crac/pull/225/files
  - new: https://git.openjdk.org/crac/pull/225/files/a4fb9789..e690c7d1

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

  Stats: 228105 lines in 5687 files changed: 113879 ins; 90749 del; 23477 mod
  Patch: https://git.openjdk.org/crac/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/225/head:pull/225

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

From tpushkin at openjdk.org  Tue May 27 12:37:42 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 27 May 2025 12:37:42 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail
In-Reply-To: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
Message-ID: <t-kJOcSO-gzeUTQjxx9y7bx-XiHCUqE8b6Mp49VqXCE=.0e70dc9b-2b35-469c-842d-60a52bc9d0e3@github.com>

On Wed, 16 Apr 2025 13:13:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
> 
> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
> 
> Also adds the since-checking tests to CI.

[JDK-8345212](https://bugs.openjdk.org/browse/JDK-8345212) works as expected. We will be able to just put `@since CRaC` to our `package-info`s and `module-info`s and add `--ignoreSince CRaC` to `SinceChecker` tests that touch CRaC sources.

I think this approach is better because we won't have to update the symbols on every release (possibly multiple times) and it seems to be the accepted way for long-running non-mainline projects (this is the reasoning in JDK-8345212).

JDK-8345212 will come with jdk-25+10, we are now at jdk-25+4. I'll leave this PR as a draft until then. After that I'll change it to satisfy JDK-8345212.

We should now use `@since CRaC` in CRaC docs and add `--ignoreSince CRaC` to since-checker tests of modules containing documented CRaC code.

I also added a disabled since-checker test for `jdk.crac` module. It can be enabled after [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.

Since-checker will also be run in our CI.

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

PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2903815445
PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2912335357

From rvansa at openjdk.org  Tue May 27 12:37:42 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 27 May 2025 12:37:42 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail
In-Reply-To: <t-kJOcSO-gzeUTQjxx9y7bx-XiHCUqE8b6Mp49VqXCE=.0e70dc9b-2b35-469c-842d-60a52bc9d0e3@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
 <t-kJOcSO-gzeUTQjxx9y7bx-XiHCUqE8b6Mp49VqXCE=.0e70dc9b-2b35-469c-842d-60a52bc9d0e3@github.com>
Message-ID: <Z3s1P_DJJ9IA5zoPc57hNl5fOlSoxFU0MphAOuxL2cc=.8f1c8cce-e4cc-4ae9-aad8-71ad80a82d2b@github.com>

On Fri, 23 May 2025 09:17:52 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
>> 
>> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
>> 
>> Also adds the since-checking tests to CI.
>
> [JDK-8345212](https://bugs.openjdk.org/browse/JDK-8345212) works as expected. We will be able to just put `@since CRaC` to our `package-info`s and `module-info`s and add `--ignoreSince CRaC` to `SinceChecker` tests that touch CRaC sources.
> 
> I think this approach is better because we won't have to update the symbols on every release (possibly multiple times) and it seems to be the accepted way for long-running non-mainline projects (this is the reasoning in JDK-8345212).
> 
> JDK-8345212 will come with jdk-25+10, we are now at jdk-25+4. I'll leave this PR as a draft until then. After that I'll change it to satisfy JDK-8345212.

@TimPushkin 25+10 was just merged.

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

PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2912146043

From duke at openjdk.org  Tue May 27 14:55:10 2025
From: duke at openjdk.org (duke)
Date: Tue, 27 May 2025 14:55:10 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail [v2]
In-Reply-To: <X2sQkd7AT730ios8GEwLjZEugastlcvBSIbpmLyqFmo=.501b3e15-b594-4c95-9730-78fe680761da@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
 <X2sQkd7AT730ios8GEwLjZEugastlcvBSIbpmLyqFmo=.501b3e15-b594-4c95-9730-78fe680761da@github.com>
Message-ID: <Jg0uYWPG2X9tcRcKpKeRIfpk2253phInRFSgru_n6C0=.b42d953f-b73c-4dd1-a7a0-bbef5e4621c5@github.com>

On Tue, 27 May 2025 12:37:42 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
>> 
>> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
>> 
>> Also adds the since-checking tests to CI.
>
> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fix since checker test with ignoreSince
>  - Revert "Fix since checker test"
>    
>    This reverts commit a4fb97899d8c6d8667b355feac655dcd6875780b.
>  - Merge remote-tracking branch 'openjdk-crac/crac' into since-checker
>  - Fix since checker test

@TimPushkin 
Your change (at version e690c7d1e5e0270df769875afb4905c28f5c7059) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2912827630

From rvansa at openjdk.org  Wed May 28 06:39:14 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 28 May 2025 06:39:14 GMT
Subject: [crac] RFR: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail [v2]
In-Reply-To: <X2sQkd7AT730ios8GEwLjZEugastlcvBSIbpmLyqFmo=.501b3e15-b594-4c95-9730-78fe680761da@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
 <X2sQkd7AT730ios8GEwLjZEugastlcvBSIbpmLyqFmo=.501b3e15-b594-4c95-9730-78fe680761da@github.com>
Message-ID: <sfRhZPTspZUvWtHN96S9CQzWiyyYrUvCQx43OK5TRgU=.34fb5cd1-00fe-4b11-844c-6f43754c9e1f@github.com>

On Tue, 27 May 2025 12:37:42 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
>> 
>> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
>> 
>> Also adds the since-checking tests to CI.
>
> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fix since checker test with ignoreSince
>  - Revert "Fix since checker test"
>    
>    This reverts commit a4fb97899d8c6d8667b355feac655dcd6875780b.
>  - Merge remote-tracking branch 'openjdk-crac/crac' into since-checker
>  - Fix since checker test

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/225#pullrequestreview-2873768897

From tpushkin at openjdk.org  Wed May 28 06:39:14 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 28 May 2025 06:39:14 GMT
Subject: [crac] Integrated: 8354679: [CRaC] jdk.crac.management makes
 JdkManagementCheckSince fail
In-Reply-To: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
References: <h71VKxi-FZKMx0UURlCncqrXeRj6Phzv4gPNfsSK_hA=.86c45394-a536-4d4c-a721-6c1a97a2109b@github.com>
Message-ID: <hUicAUQ0BeoLwagsWilJPhQu7BK3gMhACi6Qa3jx4RQ=.a2b27195-f79d-4415-92fe-c523db9fd43c@github.com>

On Wed, 16 Apr 2025 13:13:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Fixes the failing test, by using `@since CRaC` in CRaC docs and `--ignoreSince` in since-checker tests which check them.
> 
> A since-checker test for `jdk.crac` module is also added but it is disabled until [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) is fixed.
> 
> Also adds the since-checking tests to CI.

This pull request has now been integrated.

Changeset: bcb3924d
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/bcb3924de400b375506d5fccfce32f51b7ad05f0
Stats:     47 lines in 6 files changed: 45 ins; 0 del; 2 mod

8354679: [CRaC] jdk.crac.management makes JdkManagementCheckSince fail

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Wed May 28 13:25:00 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 28 May 2025 13:25:00 GMT
Subject: [crac] RFR: 8357977: [CRaC] Unused imports in CRaC's classes
Message-ID: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>

Removes unused imports from CRaC's Java code.

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

Commit messages:
 - Remove unused imports

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

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

From duke at openjdk.org  Wed May 28 15:52:17 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 15:52:17 GMT
Subject: [crac] RFR: 8357977: [CRaC] Unused imports in CRaC's classes
In-Reply-To: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
References: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
Message-ID: <snwXPqNoZ1XTr8o8fVWPwrNMQjm6QdlyAnfrjXRDTSg=.5952e18b-e276-46d4-8554-ffd21a535463@github.com>

On Wed, 28 May 2025 13:19:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Removes unused imports from CRaC's Java code.

@TimPushkin 
Your change (at version 2494ea6cf732d93beee0b0ed3b521bd9257317eb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/232#issuecomment-2916829570

From tpushkin at openjdk.org  Wed May 28 15:52:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 28 May 2025 15:52:52 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation code
Message-ID: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>

Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.

Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.

I also noted that there are no tests for new properties so I added one.

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

Commit messages:
 - Improve new properties installation code

Changes: https://git.openjdk.org/crac/pull/233/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357984
  Stats: 73 lines in 2 files changed: 51 ins; 14 del; 8 mod
  Patch: https://git.openjdk.org/crac/pull/233.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/233/head:pull/233

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

From rvansa at openjdk.org  Thu May 29 06:34:06 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 29 May 2025 06:34:06 GMT
Subject: [crac] RFR: 8357977: [CRaC] Unused imports in CRaC's classes
In-Reply-To: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
References: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
Message-ID: <ec4ZymKS9SeRTJ2wm24pDn8GIC2K3GTweWjrzitkpsM=.c04ee9f4-4890-4be7-b316-07271964a90d@github.com>

On Wed, 28 May 2025 13:19:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Removes unused imports from CRaC's Java code.

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/232#pullrequestreview-2877239958

From tpushkin at openjdk.org  Thu May 29 06:34:06 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 06:34:06 GMT
Subject: [crac] Integrated: 8357977: [CRaC] Unused imports in CRaC's classes
In-Reply-To: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
References: <xVvzCmP5B8Ro75Hi7VZvDypl8Gj-bai94E4fw9yFo1I=.88dbac6b-12ab-42f5-a1aa-af0687281637@github.com>
Message-ID: <628pNZY0_jU5HVX2cwvb1UPzmT4jp7S7f7HpPhZANTY=.4353b354-1349-4ae9-9baf-a9400b59162c@github.com>

On Wed, 28 May 2025 13:19:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Removes unused imports from CRaC's Java code.

This pull request has now been integrated.

Changeset: 9085a413
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/9085a4139efd93d937a66c09a35567e0542c5161
Stats:     8 lines in 4 files changed: 0 ins; 8 del; 0 mod

8357977: [CRaC] Unused imports in CRaC's classes

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Thu May 29 06:51:18 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 29 May 2025 06:51:18 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code
In-Reply-To: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
Message-ID: <lUSnekGT6jKWsnRTI7lABFbYnQ7DDRDW44l4yIs0w9o=.0e4aedaf-9783-4390-baeb-2d8cea83b2fb@github.com>

On Wed, 28 May 2025 15:46:42 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
> 
> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
> 
> I also noted that there are no tests for new properties so I added one.

While I also think that it should be possible to use lambdas, the deadlock was happening as a race condition, and I wonder if we could gain more confidence about this (stress test?). Or, do we consider all the restores happening in a single testsuite run sufficient?

src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 198:

> 196:             for (var prop : newProperties) {
> 197:                 String[] pair = prop.split("=", 2);
> 198:                 AccessController.doPrivileged((PrivilegedAction<Void>) () -> {

With SecurityManager obsoleted, we don't have to use `AccessController.doPrivileged` at all, do we?

src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 199:

> 197:                 String[] pair = prop.split("=", 2);
> 198:                 AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
> 199:                     System.setProperty(pair[0], pair[1]);

Looks like you have omitted the case when `prop` does not contain `=`, we would OOTB here. I guess the code that creates the properties would always add `=` (+ empty string), but let's be on the safe side.

test/jdk/jdk/crac/NewPropertyTest.java line 41:

> 39:         final var builder = new CracBuilder();
> 40:         builder.doCheckpoint();
> 41:         builder.javaOption("k", "v");

Please add `builder.vmOption("-Dfoo")` and maybe `builder.javaOptions("bar", "")` to assert on the empty property case.
Also worth checking that existing property is overridden, not only that new property is defined.

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

PR Review: https://git.openjdk.org/crac/pull/233#pullrequestreview-2877246511
PR Review Comment: https://git.openjdk.org/crac/pull/233#discussion_r2113306628
PR Review Comment: https://git.openjdk.org/crac/pull/233#discussion_r2113313559
PR Review Comment: https://git.openjdk.org/crac/pull/233#discussion_r2113320823

From tpushkin at openjdk.org  Thu May 29 07:40:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 07:40:11 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code
In-Reply-To: <lUSnekGT6jKWsnRTI7lABFbYnQ7DDRDW44l4yIs0w9o=.0e4aedaf-9783-4390-baeb-2d8cea83b2fb@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
 <lUSnekGT6jKWsnRTI7lABFbYnQ7DDRDW44l4yIs0w9o=.0e4aedaf-9783-4390-baeb-2d8cea83b2fb@github.com>
Message-ID: <3i1ex9tL5iJCkzMdTeViV83x7V4VIl9NG8luf9B_NKY=.21a80b21-0648-46fc-8c32-3605d0a9c212@github.com>

On Thu, 29 May 2025 06:33:38 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
>> 
>> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
>> 
>> I also noted that there are no tests for new properties so I added one.
>
> src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 198:
> 
>> 196:             for (var prop : newProperties) {
>> 197:                 String[] pair = prop.split("=", 2);
>> 198:                 AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
> 
> With SecurityManager obsoleted, we don't have to use `AccessController.doPrivileged` at all, do we?

Actually yes, I'll remove it. But it is so because of its deletion in JDK 24 and not because of its obsoletion in JDK 17: between 17 and 24 it can still be enabled so we'll have to bring `doPrivileged` back when backporting.

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

PR Review Comment: https://git.openjdk.org/crac/pull/233#discussion_r2113397270

From tpushkin at openjdk.org  Thu May 29 07:44:03 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 07:44:03 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code
In-Reply-To: <lUSnekGT6jKWsnRTI7lABFbYnQ7DDRDW44l4yIs0w9o=.0e4aedaf-9783-4390-baeb-2d8cea83b2fb@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
 <lUSnekGT6jKWsnRTI7lABFbYnQ7DDRDW44l4yIs0w9o=.0e4aedaf-9783-4390-baeb-2d8cea83b2fb@github.com>
Message-ID: <aB3K5gmt8XuMWK2KV_HVaI2Er80AAN5PB17JXIqfwuU=.187fdd47-cbec-4519-b51a-92897f76cba9@github.com>

On Thu, 29 May 2025 06:39:02 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
>> 
>> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
>> 
>> I also noted that there are no tests for new properties so I added one.
>
> src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 199:
> 
>> 197:                 String[] pair = prop.split("=", 2);
>> 198:                 AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
>> 199:                     System.setProperty(pair[0], pair[1]);
> 
> Looks like you have omitted the case when `prop` does not contain `=`, we would OOTB here. I guess the code that creates the properties would always add `=` (+ empty string), but let's be on the safe side.

Yes, `=` will always be there: https://github.com/openjdk/crac/blob/9085a4139efd93d937a66c09a35567e0542c5161/src/hotspot/share/runtime/crac_structs.hpp#L139, but OK I'll do a check and add a test.

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

PR Review Comment: https://git.openjdk.org/crac/pull/233#discussion_r2113403638

From tpushkin at openjdk.org  Thu May 29 08:20:02 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 08:20:02 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code [v2]
In-Reply-To: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
Message-ID: <irQ9De3h8VLhJ3f0x2hfDMT-9CLkip768BFFvPRUFFo=.4b9fcf6a-6485-4a45-9f71-eca2255e0302@github.com>

> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
> 
> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
> 
> I also noted that there are no tests for new properties so I added one.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/crac/pull/233/files
  - new: https://git.openjdk.org/crac/pull/233/files/fa9f80ba..8421e5e6

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

  Stats: 124 lines in 3 files changed: 67 ins; 55 del; 2 mod
  Patch: https://git.openjdk.org/crac/pull/233.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/233/head:pull/233

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

From rvansa at openjdk.org  Thu May 29 08:32:15 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 29 May 2025 08:32:15 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code [v2]
In-Reply-To: <irQ9De3h8VLhJ3f0x2hfDMT-9CLkip768BFFvPRUFFo=.4b9fcf6a-6485-4a45-9f71-eca2255e0302@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
 <irQ9De3h8VLhJ3f0x2hfDMT-9CLkip768BFFvPRUFFo=.4b9fcf6a-6485-4a45-9f71-eca2255e0302@github.com>
Message-ID: <xRWxWR6wMzbSHXLd492aCwcGZGSctzU7wCr9ZYtzK9g=.3f273f65-0b46-4e6a-baae-f5032a961d7c@github.com>

On Thu, 29 May 2025 08:20:02 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
>> 
>> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
>> 
>> I also noted that there are no tests for new properties so I added one.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/233#pullrequestreview-2877509654

From akozlov at azul.com  Thu May 29 09:14:52 2025
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 29 May 2025 12:14:52 +0300
Subject: Result: New CRaC Committer: Timofei Pushkin
Message-ID: <e3526e77-7d05-4d46-8546-0e207cfbeb0c@azul.com>

Voting for Timofei Pushkin [1] is now closed.

Yes: 2
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Anton Kozlov

[1] https://mail.openjdk.org/pipermail/crac-dev/2025-April/002308.html

From duke at openjdk.org  Thu May 29 10:46:07 2025
From: duke at openjdk.org (duke)
Date: Thu, 29 May 2025 10:46:07 GMT
Subject: [crac] RFR: 8357984: [CRaC] Improve new properties installation
 code [v2]
In-Reply-To: <irQ9De3h8VLhJ3f0x2hfDMT-9CLkip768BFFvPRUFFo=.4b9fcf6a-6485-4a45-9f71-eca2255e0302@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
 <irQ9De3h8VLhJ3f0x2hfDMT-9CLkip768BFFvPRUFFo=.4b9fcf6a-6485-4a45-9f71-eca2255e0302@github.com>
Message-ID: <e27bpa7qBDi6QLdF-yvO_EgnEy9yh05EnImKuq1Ly8g=.f0e9d501-0166-42d0-af3f-71530de56395@github.com>

On Thu, 29 May 2025 08:20:02 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
>> 
>> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
>> 
>> I also noted that there are no tests for new properties so I added one.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

@TimPushkin 
Your change (at version 8421e5e6dee95ba26d63dbce72a1d367795f81ab) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/233#issuecomment-2919016043

From tpushkin at openjdk.org  Thu May 29 11:08:41 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 11:08:41 GMT
Subject: [crac] RFR: 8358063: [CRaC] Excessive PosixAttachListener-related
 availability and references
Message-ID: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>

Makes `PosixAttachListener` and `PosixAttachOperation` declared, defined and referenced only when they are implemented.

Sadly, I don't have access to AIX to test the buildability there.

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

Commit messages:
 - Remove PosixAttachListener definition on AIX

Changes: https://git.openjdk.org/crac/pull/234/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358063
  Stats: 14 lines in 3 files changed: 6 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/crac/pull/234.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/234/head:pull/234

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

From duke at openjdk.org  Thu May 29 11:17:03 2025
From: duke at openjdk.org (duke)
Date: Thu, 29 May 2025 11:17:03 GMT
Subject: [crac] RFR: 8358063: [CRaC] Excessive PosixAttachListener-related
 availability and references
In-Reply-To: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
References: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
Message-ID: <W7Q9_ym4g1uhFd5xqhJ1q03DLfrdI561JV8D9KFZyyk=.fa76a903-d460-47c8-9772-8237129b242b@github.com>

On Thu, 29 May 2025 11:02:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `PosixAttachListener` and `PosixAttachOperation` declared, defined and referenced only when they are implemented. This makes the sources closer to the mainline where these classes are defined in `.cpp` files under `#if INCLUDE_SERVICES #ifndef AIX` guards.
> 
> Sadly, I don't have access to AIX to test the buildability there.

@TimPushkin 
Your change (at version b462d87ec095543b5ee67f73b07e22657b7cfb63) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/234#issuecomment-2919084671

From rvansa at openjdk.org  Thu May 29 13:43:05 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 29 May 2025 13:43:05 GMT
Subject: [crac] RFR: 8358063: [CRaC] Excessive PosixAttachListener-related
 availability and references
In-Reply-To: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
References: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
Message-ID: <eMIfu4GZtuDBWhUlxcnqSVlkzrVFgJxYSH-ZkyfF0I0=.7491c3d7-dcb5-47c9-93bc-1a8e38a92827@github.com>

On Thu, 29 May 2025 11:02:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `PosixAttachListener` and `PosixAttachOperation` declared, defined and referenced only when they are implemented. This makes the sources closer to the mainline where these classes are defined in `.cpp` files under `#if INCLUDE_SERVICES #ifndef AIX` guards.
> 
> Sadly, I don't have access to AIX to test the buildability there.

LGTM. Btw. could you interlink this PR with the PR to OpenJDK/jdk that tries to upstream the refactoring into own files?

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/234#pullrequestreview-2878320722

From tpushkin at openjdk.org  Thu May 29 13:43:06 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 13:43:06 GMT
Subject: [crac] Integrated: 8358063: [CRaC] Excessive
 PosixAttachListener-related availability and references
In-Reply-To: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
References: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
Message-ID: <si2I88c5nICeaVX9Z4dKZRxDAm9JZG6RL2RQo9MKs_E=.30fd9b8a-2ee5-449f-bc04-66de3bbf0561@github.com>

On Thu, 29 May 2025 11:02:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `PosixAttachListener` and `PosixAttachOperation` declared, defined and referenced only when they are implemented. This makes the sources closer to the mainline where these classes are defined in `.cpp` files under `#if INCLUDE_SERVICES #ifndef AIX` guards.
> 
> Sadly, I don't have access to AIX to test the buildability there.

This pull request has now been integrated.

Changeset: f2db1d6e
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/f2db1d6e949d806d1ecef4e2e72557822b677db5
Stats:     14 lines in 3 files changed: 6 ins; 4 del; 4 mod

8358063: [CRaC] Excessive PosixAttachListener-related availability and references

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Thu May 29 13:47:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 13:47:11 GMT
Subject: [crac] Integrated: 8357984: [CRaC] Improve new properties installation
 code
In-Reply-To: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
References: <ml9nRQlW2RuTuejQKee3TYoVkQzs7zxgwdXti89Yf6A=.89438409-d2fb-4fbd-9cd9-99b2de129222@github.com>
Message-ID: <oS3A0V3Kxp5qYvsdWiZZYZyKfHEeU7vyYh3wBJ4o1uw=.ace2c8b3-f6e5-4c5d-bdf0-2ff5a3d504f7@github.com>

On Wed, 28 May 2025 15:46:42 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Rewrites the code which installs new properties on restore to make it more concise by using direct array iteration and lambdas.
> 
> Note that initially the lambdas were removed from this code in #75 because they triggered a resource registration in a blocking context during C/R which led to a deadlock. But as I understand #73 made it possible to use lambdas during C/R.
> 
> I also noted that there are no tests for new properties so I added one.

This pull request has now been integrated.

Changeset: 19d203ae
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/19d203aee40073b701d9875b18e652627b84ea90
Stats:     90 lines in 2 files changed: 67 ins; 18 del; 5 mod

8357984: [CRaC] Improve new properties installation code

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Thu May 29 14:07:07 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 May 2025 14:07:07 GMT
Subject: [crac] RFR: 8358063: [CRaC] Excessive PosixAttachListener-related
 availability and references
In-Reply-To: <eMIfu4GZtuDBWhUlxcnqSVlkzrVFgJxYSH-ZkyfF0I0=.7491c3d7-dcb5-47c9-93bc-1a8e38a92827@github.com>
References: <za7HeOTYzj7b2nTYu7g5tVkGiU2WktA2qLYk-DN0u1c=.70f279a8-ac40-4779-9dbb-9ff5039b2efa@github.com>
 <eMIfu4GZtuDBWhUlxcnqSVlkzrVFgJxYSH-ZkyfF0I0=.7491c3d7-dcb5-47c9-93bc-1a8e38a92827@github.com>
Message-ID: <SqpGblzp4uVA4LbcLGFGCQpo1Mp-jcQVcxt62xR_CJw=.fa02dbf7-4969-47cf-afb1-44a9b5b58256@github.com>

On Thu, 29 May 2025 13:39:19 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Btw. could you interlink this PR with the PR to OpenJDK/jdk that tries to upstream the refactoring into own files?

I've linked the JBS issues.

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

PR Comment: https://git.openjdk.org/crac/pull/234#issuecomment-2919517001

From tpushkin at openjdk.org  Fri May 30 12:54:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 30 May 2025 12:54:17 GMT
Subject: [crac] RFR: 8358161: [CRaC] Make VM-controlled options
 engine-dependent
Message-ID: <m_JSBJzw2l1se1cnmjeXNu7Zz0XnZs_ihT3eNpdDdOE=.b0eae05f-80bb-4f81-8179-a882b63ec126@github.com>

"Configuration options controlled by the JVM: ..." section of `-XX:CRaCEngineOptions=help` will now only list the options which are supported by the current engine.

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

Commit messages:
 - Make VM-controlled options CRE-dependent

Changes: https://git.openjdk.org/crac/pull/235/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358161
  Stats: 26 lines in 3 files changed: 15 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/crac/pull/235.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/235/head:pull/235

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