From tpushkin at openjdk.org  Mon Feb  2 07:32:50 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 07:32:50 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v5]
In-Reply-To: <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@github.com>
Message-ID: <LATW8KiVkECfvKyLTC8KDzKiFVzK5dK-S_Mo6HGhXSs=.8f5a9e50-d583-4dfc-b6ba-e2f621bc977d@github.com>

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

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

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

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

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

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

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

Allocation should be checked for success

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

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

From rvansa at openjdk.org  Mon Feb  2 08:09:49 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Feb 2026 08:09:49 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v6]
In-Reply-To: <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@github.com>
Message-ID: <PCLYe8mCsx__10QZKIXDLyLY303b8U-9mQcba5jjWgg=.7d7cd5b4-aa31-4374-be40-02b87aff0d5d@github.com>

On Sat, 31 Jan 2026 13:31:03 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

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

src/hotspot/share/include/crlib/crlib_image_constraints.h line 68:

> 66: 
> 67:   // For failed require_bitmap it will copy value from the image to the provided buffer.
> 68:   bool (*get_failed_bitmap)(crlib_conf_t *, const char *name, unsigned char *value_return, size_t value_size);

>From this API, I don't see how you'd get to know the size of the stored value. Could you either report that as the return value (`-1` => error retrieving, `0` => bitmap missing or empty)?
Alternatively `value_size` could be an in-out argument. (the former would be inline with `crlib_restore_data::get_restore_data`, the latter is used in `crlib_user_data::lookup_user_data`)
And add a comment describing the return value/parameter.

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

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

From rvansa at openjdk.org  Mon Feb  2 10:43:25 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Feb 2026 10:43:25 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
 <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
Message-ID: <OZYgm9nHF74U-Gl8FN3ZzXy7EUW-bIpvBDQVyG2cBI8=.69dd5ba8-1743-4deb-8f0c-4c3b524f3df9@github.com>

On Thu, 29 Jan 2026 09:00:10 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Merge of mainline up to tag `jdk-27+5`.
>> 
>> Output of `git show --remerge-diff`: https://gist.github.com/TimPushkin/08b5f317377b4f3be0d13a83600af362
>> 
>> Major conflicts/changes:
>> - Removed a bunch of expired VM options
>> - Removed uses of `IgnoreCPUFeatures` as it becomes obsoleted with 27
>> - Sorted includes with `test/hotspot/jtreg/sources/SortIncludes.java` because there's now a test checking the include order in CI
>> - Replaced `snprintf` with `os::snprintf` because the use of the former now fails the build (it is marked deprecated)
>> - Moved code that cleans heap before checkpoint because of changes in GCs: [JDK-8368740](https://bugs.openjdk.org/browse/JDK-8368740) (Serial), [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977) (Parallel), [JDK-8238687](https://bugs.openjdk.org/browse/JDK-8238687) (G1)
>> - Handled the new `HYBRID` CPU feature as not GLIBC-tunable ? not sure if it is indeed not tunable (don't know how to check reliably)
>> - Rewrote CPU features to string conversions to use `stringStream` because of [JDK-8364128](https://bugs.openjdk.org/browse/JDK-8364128)
>> - Deferred initialization of `JDKFileResource.CLASSPATH_ENTRIES` until checkpoint: having it static changed the order of static initializations during VM startup from what is in the mainline in a way that class loading from CDS-archived JDK modules broke. When starting from a CDS archive, `ArchivedClassLoaders` and `BuiltinClassLoader` have a circular static-init dependency, and in CRaC the order was "wrong". I'd say that this is a CDS bug but it seems easier for us to apply this workaround, plus it improves performance when C/R is not used.
>> - Separated Docker code from `CracBuilder` into `CracContainerBuilder`: because of https://github.com/openjdk/jdk/pull/28557#issuecomment-3597274354 all tests that use `DockerTestUtils` now require `@modules java.base/jdk.internal.platform`, so all CRaC tests that use `CracContainerBuilder` now require it
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

The changes due to GC look like there is some chance for a regression. I wonder if we have something to run to validate that there's none.

In the `CracBuilder` changes, I am not really sure if changing the type used by tests is a good thing. I like isolating the container-related code to a separate class, but encapsulation would be my first choice rather than inheritance in this case.

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

PR Comment: https://git.openjdk.org/crac/pull/288#issuecomment-3834333221

From tpushkin at openjdk.org  Mon Feb  2 11:13:46 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 11:13:46 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <OZYgm9nHF74U-Gl8FN3ZzXy7EUW-bIpvBDQVyG2cBI8=.69dd5ba8-1743-4deb-8f0c-4c3b524f3df9@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
 <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
 <OZYgm9nHF74U-Gl8FN3ZzXy7EUW-bIpvBDQVyG2cBI8=.69dd5ba8-1743-4deb-8f0c-4c3b524f3df9@github.com>
Message-ID: <MFNIGeZXeuLXOkzM_WpIjhzkWTJCN-lkLE_OTQ5eOls=.c56732ee-9946-4635-bd35-bf620e9cea3a@github.com>

On Mon, 2 Feb 2026 10:40:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> The changes due to GC look like there is some chance for a regression. I wonder if we have something to run to validate that there's none.

I ran a helidon-based benchmark I used for the related changes in G1 and checked that removing `Universe::heap()->set_cleanup_unused(true)` in `crac.cpp` leads to CRIU image size increasing significantly for the 3 affected GCs. For G1 I also checked that the excess GCs I was fixing by those changes do not come back (with `Universe::heap()->set_cleanup_unused(true)` in place).

> In the `CracBuilder` changes, I am not really sure if changing the type used by tests is a good thing. I like isolating the container-related code to a separate class, but encapsulation would be my first choice rather than inheritance in this case.

I think encapsulation would result in more complicated code, if possible at all: `CracBuilder` cannot reference `CracContainerBuilder` because that would be a transitive reference to `DockerTestUtils` ? the thing we want to avoid.

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

PR Comment: https://git.openjdk.org/crac/pull/288#issuecomment-3834479471

From rvansa at openjdk.org  Mon Feb  2 14:58:05 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Feb 2026 14:58:05 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <MFNIGeZXeuLXOkzM_WpIjhzkWTJCN-lkLE_OTQ5eOls=.c56732ee-9946-4635-bd35-bf620e9cea3a@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
 <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
 <OZYgm9nHF74U-Gl8FN3ZzXy7EUW-bIpvBDQVyG2cBI8=.69dd5ba8-1743-4deb-8f0c-4c3b524f3df9@github.com>
 <MFNIGeZXeuLXOkzM_WpIjhzkWTJCN-lkLE_OTQ5eOls=.c56732ee-9946-4635-bd35-bf620e9cea3a@github.com>
Message-ID: <F4-KHxmOQaymVQWE1GhjVD1OTWTFaoSA6722oQBH4LU=.a087ea22-1207-4fbf-a0a2-769c134e9aaa@github.com>

On Mon, 2 Feb 2026 11:10:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> I ran a helidon-based benchmark I used for the related changes in G1 and checked that removing Universe::heap()->set_cleanup_unused(true) in crac.cpp leads to CRIU image size increasing significantly for the 3 affected GCs. For G1 I also checked that the excess GCs I was fixing by those changes do not come back (with Universe::heap()->set_cleanup_unused(true) in place).

Sounds like you tested that it does something; have you checked absolute sizes of the images before and after the change?

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

PR Comment: https://git.openjdk.org/crac/pull/288#issuecomment-3835619808

From jkratochvil at openjdk.org  Mon Feb  2 14:59:41 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Feb 2026 14:59:41 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v7]
In-Reply-To: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <SvEZ1OrIgGy7QLUYjCg0jj6i9Q4HiK6_x2lQ_JNfGGA=.c8301e89-2b08-42a8-858e-1eeb98d1f0d2@github.com>

> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
> 
> 
> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
> 
> 
> is wrong as it does not do logical and of both CPUFeatures masks.
> 
> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
> 
> @rvansa will probably want to change the API but this is a PoC how it should work.

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

 - Use current_features everywhere
 - Fix "try using -XX:CPUFeatures" for the 'exact' case.
 - Check for failed malloc

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/90633b09..b447735d

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

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

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

From tpushkin at openjdk.org  Mon Feb  2 15:02:37 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 15:02:37 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <F4-KHxmOQaymVQWE1GhjVD1OTWTFaoSA6722oQBH4LU=.a087ea22-1207-4fbf-a0a2-769c134e9aaa@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
 <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
 <OZYgm9nHF74U-Gl8FN3ZzXy7EUW-bIpvBDQVyG2cBI8=.69dd5ba8-1743-4deb-8f0c-4c3b524f3df9@github.com>
 <MFNIGeZXeuLXOkzM_WpIjhzkWTJCN-lkLE_OTQ5eOls=.c56732ee-9946-4635-bd35-bf620e9cea3a@github.com>
 <F4-KHxmOQaymVQWE1GhjVD1OTWTFaoSA6722oQBH4LU=.a087ea22-1207-4fbf-a0a2-769c134e9aaa@github.com>
Message-ID: <QpCusfAqI5PijQe48HT-mnNHr_TRfhH_vgapI269SF8=.b66391ed-d377-4e4d-8728-eb2cf8405113@github.com>

On Mon, 2 Feb 2026 14:55:29 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Sounds like you tested that it does something; have you checked absolute sizes of the images before and after the change?

Well, they differ and it is to be expected because there is a half a year difference in the JDK.

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

PR Comment: https://git.openjdk.org/crac/pull/288#issuecomment-3835642116

From jkratochvil at openjdk.org  Mon Feb  2 15:04:50 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Feb 2026 15:04:50 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v5]
In-Reply-To: <LATW8KiVkECfvKyLTC8KDzKiFVzK5dK-S_Mo6HGhXSs=.8f5a9e50-d583-4dfc-b6ba-e2f621bc977d@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@github.com>
 <LATW8KiVkECfvKyLTC8KDzKiFVzK5dK-S_Mo6HGhXSs=.8f5a9e50-d583-4dfc-b6ba-e2f621bc977d@github.com>
Message-ID: <BJXKfoVOqoimMNtiGlLOUsbNNkcTr5mhqYPbFM6-abk=.de48d0d9-89d5-47f4-ab3c-ca0edd1f774d@github.com>

On Mon, 2 Feb 2026 07:28:00 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get_failed_bitmap to return stored data
>
> src/hotspot/share/runtime/crac_engine.cpp line 514:
> 
>> 512:         image_features &= *datap;
>> 513:       }
>> 514:       log_error(crac)("Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=%s on checkpoint.", image_features.print_numbers());
> 
> In the exact case with this wording I believe `datap` should be printed, not `image_features`. Maybe it's a good idea to rename `datap` to `current_features` to avoid confusion, and also make it a reference instead of a pointer.

Fixed the exact case, thanks. Renamed it to `current_features` everywhere.

I normally used references for any non-null pointer everywhere but OpenJDK does not do that. I haven't found a coding style rule for it but apparently OpenJDK discourages references. Why do you suggest to use a reference here?

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

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

From rvansa at openjdk.org  Mon Feb  2 15:09:20 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Feb 2026 15:09:20 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
 <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>
Message-ID: <VPKgTxdyhb82xUyK0AO8pSUxAegXOGyw-1bu_KVwEgw=.04863255-9787-416b-80ad-7c71543a8fbd@github.com>

On Thu, 29 Jan 2026 09:00:10 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Merge of mainline up to tag `jdk-27+5`.
>> 
>> Output of `git show --remerge-diff`: https://gist.github.com/TimPushkin/08b5f317377b4f3be0d13a83600af362
>> 
>> Major conflicts/changes:
>> - Removed a bunch of expired VM options
>> - Removed uses of `IgnoreCPUFeatures` as it becomes obsoleted with 27
>> - Sorted includes with `test/hotspot/jtreg/sources/SortIncludes.java` because there's now a test checking the include order in CI
>> - Replaced `snprintf` with `os::snprintf` because the use of the former now fails the build (it is marked deprecated)
>> - Moved code that cleans heap before checkpoint because of changes in GCs: [JDK-8368740](https://bugs.openjdk.org/browse/JDK-8368740) (Serial), [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977) (Parallel), [JDK-8238687](https://bugs.openjdk.org/browse/JDK-8238687) (G1)
>> - Handled the new `HYBRID` CPU feature as not GLIBC-tunable ? not sure if it is indeed not tunable (don't know how to check reliably)
>> - Rewrote CPU features to string conversions to use `stringStream` because of [JDK-8364128](https://bugs.openjdk.org/browse/JDK-8364128)
>> - Deferred initialization of `JDKFileResource.CLASSPATH_ENTRIES` until checkpoint: having it static changed the order of static initializations during VM startup from what is in the mainline in a way that class loading from CDS-archived JDK modules broke. When starting from a CDS archive, `ArchivedClassLoaders` and `BuiltinClassLoader` have a circular static-init dependency, and in CRaC the order was "wrong". I'd say that this is a CDS bug but it seems easier for us to apply this workaround, plus it improves performance when C/R is not used.
>> - Separated Docker code from `CracBuilder` into `CracContainerBuilder`: because of https://github.com/openjdk/jdk/pull/28557#issuecomment-3597274354 all tests that use `DockerTestUtils` now require `@modules java.base/jdk.internal.platform`, so all CRaC tests that use `CracContainerBuilder` now require it
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/288#pullrequestreview-3740038831

From tpushkin at openjdk.org  Mon Feb  2 15:14:45 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 15:14:45 GMT
Subject: [crac] Integrated: Merge jdk:jdk-27+5
In-Reply-To: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
Message-ID: <lORY82uC95TJzEsyoQ8qdHmuKavdg44X3X1N4L1PgNA=.1ad33673-4fee-4a0f-9340-36e6d602ab56@github.com>

On Wed, 28 Jan 2026 08:18:08 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Merge of mainline up to tag `jdk-27+5`.
> 
> Output of `git show --remerge-diff`: https://gist.github.com/TimPushkin/08b5f317377b4f3be0d13a83600af362
> 
> Major conflicts/changes:
> - Removed a bunch of expired VM options
> - Removed uses of `IgnoreCPUFeatures` as it becomes obsoleted with 27
> - Sorted includes with `test/hotspot/jtreg/sources/SortIncludes.java` because there's now a test checking the include order in CI
> - Replaced `snprintf` with `os::snprintf` because the use of the former now fails the build (it is marked deprecated)
> - Moved code that cleans heap before checkpoint because of changes in GCs: [JDK-8368740](https://bugs.openjdk.org/browse/JDK-8368740) (Serial), [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977) (Parallel), [JDK-8238687](https://bugs.openjdk.org/browse/JDK-8238687) (G1)
> - Handled the new `HYBRID` CPU feature as not GLIBC-tunable ? not sure if it is indeed not tunable (don't know how to check reliably)
> - Rewrote CPU features to string conversions to use `stringStream` because of [JDK-8364128](https://bugs.openjdk.org/browse/JDK-8364128)
> - Deferred initialization of `JDKFileResource.CLASSPATH_ENTRIES` until checkpoint: having it static changed the order of static initializations during VM startup from what is in the mainline in a way that class loading from CDS-archived JDK modules broke. When starting from a CDS archive, `ArchivedClassLoaders` and `BuiltinClassLoader` have a circular static-init dependency, and in CRaC the order was "wrong". I'd say that this is a CDS bug but it seems easier for us to apply this workaround, plus it improves performance when C/R is not used.
> - Separated Docker code from `CracBuilder` into `CracContainerBuilder`: because of https://github.com/openjdk/jdk/pull/28557#issuecomment-3597274354 all tests that use `DockerTestUtils` now require `@modules java.base/jdk.internal.platform`, so all CRaC tests that use `CracContainerBuilder` now require it

This pull request has now been integrated.

Changeset: 2f0af59e
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/2f0af59e4d38d4f48bccf21f7c1515625597f749
Stats:     825701 lines in 10640 files changed: 544360 ins; 173424 del; 107917 mod

Merge jdk:jdk-27+5

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Mon Feb  2 15:43:35 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 15:43:35 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v5]
In-Reply-To: <BJXKfoVOqoimMNtiGlLOUsbNNkcTr5mhqYPbFM6-abk=.de48d0d9-89d5-47f4-ab3c-ca0edd1f774d@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@github.com>
 <LATW8KiVkECfvKyLTC8KDzKiFVzK5dK-S_Mo6HGhXSs=.8f5a9e50-d583-4dfc-b6ba-e2f621bc977d@github.com>
 <BJXKfoVOqoimMNtiGlLOUsbNNkcTr5mhqYPbFM6-abk=.de48d0d9-89d5-47f4-ab3c-ca0edd1f774d@github.com>
Message-ID: <8uomeeIKmQAUdxTRcspqtpp2J3XL_yBZ0KbHPL1NnSc=.b3e2538e-3dc0-4dd5-a750-e98646981f75@github.com>

On Mon, 2 Feb 2026 15:02:07 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.cpp line 514:
>> 
>>> 512:         image_features &= *datap;
>>> 513:       }
>>> 514:       log_error(crac)("Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=%s on checkpoint.", image_features.print_numbers());
>> 
>> In the exact case with this wording I believe `datap` should be printed, not `image_features`. Maybe it's a good idea to rename `datap` to `current_features` to avoid confusion, and also make it a reference instead of a pointer.
>
> Fixed the exact case, thanks. Renamed it to `current_features` everywhere.
> 
> I normally used references for any non-null pointer everywhere but OpenJDK does not do that. I haven't found a coding style rule for it but apparently OpenJDK discourages references. Why do you suggest to use a reference here?

I usually use a pointer-to-class/struct parameter only if it either nullable, the function actually needs a pointer (e.g. does pointer arithmetic), or the function mutates the object (i.e. it's a non-const reference). And even the last two are debatable. Otherwise using a pointer makes the syntax bulkier and makes the function declaration less self-documenting (a pointer allows null).

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

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

From tpushkin at openjdk.org  Mon Feb  2 15:43:36 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 2 Feb 2026 15:43:36 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v5]
In-Reply-To: <8uomeeIKmQAUdxTRcspqtpp2J3XL_yBZ0KbHPL1NnSc=.b3e2538e-3dc0-4dd5-a750-e98646981f75@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@github.com>
 <LATW8KiVkECfvKyLTC8KDzKiFVzK5dK-S_Mo6HGhXSs=.8f5a9e50-d583-4dfc-b6ba-e2f621bc977d@github.com>
 <BJXKfoVOqoimMNtiGlLOUsbNNkcTr5mhqYPbFM6-abk=.de48d0d9-89d5-47f4-ab3c-ca0edd1f774d@github.com>
 <8uomeeIKmQAUdxTRcspqtpp2J3XL_yBZ0KbHPL1NnSc=.b3e2538e-3dc0-4dd5-a750-e98646981f75@github.com>
Message-ID: <qKZmhxJAoOnjt8KhU2Bh1XpjrLTsj1XXxnxi-SAr4r8=.17ad500b-6ed6-44cd-b4fb-c1e8dbf7c0a7@github.com>

On Mon, 2 Feb 2026 15:37:41 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Fixed the exact case, thanks. Renamed it to `current_features` everywhere.
>> 
>> I normally used references for any non-null pointer everywhere but OpenJDK does not do that. I haven't found a coding style rule for it but apparently OpenJDK discourages references. Why do you suggest to use a reference here?
>
> I usually use a pointer-to-class/struct parameter only if it either nullable, the function actually needs a pointer (e.g. does pointer arithmetic), or the function mutates the object (i.e. it's a non-const reference). And even the last two are debatable. Otherwise using a pointer makes the syntax bulkier and makes the function declaration less self-documenting (a pointer allows null).

That is just my opinion, since HotSpot style guide does not have a hard opinion on this (and I don't think it discourages references in any way) I would approve even if this stays a pointer.

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

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

From rvansa at openjdk.org  Mon Feb  2 17:19:52 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Feb 2026 17:19:52 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
Message-ID: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>

Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.

The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).

We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

Commit messages:
 - JDK-8376959: [CRaC] Turn simengine into shared library

Changes: https://git.openjdk.org/crac/pull/289/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=289&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376959
  Stats: 2810 lines in 26 files changed: 1602 ins; 1145 del; 63 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From jkratochvil at openjdk.org  Mon Feb  2 20:30:31 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Feb 2026 20:30:31 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v6]
In-Reply-To: <PCLYe8mCsx__10QZKIXDLyLY303b8U-9mQcba5jjWgg=.7d7cd5b4-aa31-4374-be40-02b87aff0d5d@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@github.com>
 <PCLYe8mCsx__10QZKIXDLyLY303b8U-9mQcba5jjWgg=.7d7cd5b4-aa31-4374-be40-02b87aff0d5d@github.com>
Message-ID: <DL3_XNdGMMHZTJ1QfogBVunS8N0oPuSFqwAJ-2Ds0gk=.4a5c2c6e-e637-431b-9e13-5214c36a7ad8@github.com>

On Mon, 2 Feb 2026 08:06:40 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-x86 builds
>
> src/hotspot/share/include/crlib/crlib_image_constraints.h line 68:
> 
>> 66: 
>> 67:   // For failed require_bitmap it will copy value from the image to the provided buffer.
>> 68:   bool (*get_failed_bitmap)(crlib_conf_t *, const char *name, unsigned char *value_return, size_t value_size);
> 
> From this API, I don't see how you'd get to know the size of the stored value. Could you either report that as the return value (`-1` => error retrieving, `0` => bitmap missing or empty)?
> Alternatively `value_size` could be an in-out argument. (the former would be inline with `crlib_restore_data::get_restore_data`, the latter is used in `crlib_user_data::lookup_user_data`)
> And add a comment describing the return value/parameter.

Currently, if the size does not match, it always fails:

        if (value_return) { 
          if (!c.image_data || value_size != c.data_size) {
            result = false;

This means that the version of OpenJDK used for restoring is different from the one used for snapshotting, which will result in:

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

It would be possible, but difficult, to print the CPU features if their size differs from `sizeof(VM_Version::VM_Features)`. I don't think we need to support running mismatched OpenJDK versions extensively.

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

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

From rvansa at openjdk.org  Tue Feb  3 09:37:34 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 09:37:34 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

  Implement static build & other platforms

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/3beab720..1ea5ad88

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

  Stats: 89 lines in 5 files changed: 65 ins; 9 del; 15 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From rvansa at openjdk.org  Tue Feb  3 09:45:28 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 09:45:28 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v6]
In-Reply-To: <DL3_XNdGMMHZTJ1QfogBVunS8N0oPuSFqwAJ-2Ds0gk=.4a5c2c6e-e637-431b-9e13-5214c36a7ad8@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@github.com>
 <PCLYe8mCsx__10QZKIXDLyLY303b8U-9mQcba5jjWgg=.7d7cd5b4-aa31-4374-be40-02b87aff0d5d@github.com>
 <DL3_XNdGMMHZTJ1QfogBVunS8N0oPuSFqwAJ-2Ds0gk=.4a5c2c6e-e637-431b-9e13-5214c36a7ad8@github.com>
Message-ID: <eOSG0HpfuRk6mmlZkml1pJGbFNZwZjnpLuz4ePDV6UY=.b3d5b083-7f77-43ac-9070-b835ede89179@github.com>

On Mon, 2 Feb 2026 20:28:07 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/include/crlib/crlib_image_constraints.h line 68:
>> 
>>> 66: 
>>> 67:   // For failed require_bitmap it will copy value from the image to the provided buffer.
>>> 68:   bool (*get_failed_bitmap)(crlib_conf_t *, const char *name, unsigned char *value_return, size_t value_size);
>> 
>> From this API, I don't see how you'd get to know the size of the stored value. Could you either report that as the return value (`-1` => error retrieving, `0` => bitmap missing or empty)?
>> Alternatively `value_size` could be an in-out argument. (the former would be inline with `crlib_restore_data::get_restore_data`, the latter is used in `crlib_user_data::lookup_user_data`)
>> And add a comment describing the return value/parameter.
>
> Currently, if the size does not match, it always fails:
> 
>         if (value_return) { 
>           if (!c.image_data || value_size != c.data_size) {
>             result = false;
> 
> This means that the version of OpenJDK used for restoring is different from the one used for snapshotting, which will result in:
> 
>       log_error(crac)("Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=%s on checkpoint.", image_features.print_numbers());
>     } else {
> -->   log_error(crac)("Restore failed due to incompatible or missing CPU features.");
> 
> It would be possible, but difficult, to print the CPU features if their size differs from `sizeof(VM_Version::VM_Features)`. I don't think we need to support running mismatched OpenJDK versions extensively.

I see, so you just assume that the user will guess the right size, or get an error. I am not saying that you should print a partial bitmap; I think that

if (api->get_failed_bitmap(..., sizeof(image_features)) != sizeof(image_features)) {
  // error
}

would be an OK implementation. Just worried about cementing a limitation into the API.

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

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

From rvansa at openjdk.org  Tue Feb  3 13:20:30 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 13:20:30 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v3]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <mozUa47N3xVmEbb0rgwpVcbfA9hrq0akdHGrO3UEA88=.c16973eb-b80c-4f01-953a-d7c24919e676@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

  Fixups

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/1ea5ad88..fbd07e66

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

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

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

From tpushkin at openjdk.org  Tue Feb  3 14:06:23 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 14:06:23 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v3]
In-Reply-To: <mozUa47N3xVmEbb0rgwpVcbfA9hrq0akdHGrO3UEA88=.c16973eb-b80c-4f01-953a-d7c24919e676@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <mozUa47N3xVmEbb0rgwpVcbfA9hrq0akdHGrO3UEA88=.c16973eb-b80c-4f01-953a-d7c24919e676@github.com>
Message-ID: <_7JmXVhjoER_fwXg3kyWl2la05FqWO1PG60Bk4V5Tqs=.b5ed45c9-d0a5-4a4b-ac57-944b18b1d1b1@github.com>

On Tue, 3 Feb 2026 13:20:30 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

I skipped most of crexec changes since we plan to remove it soon.

Looks like the README should now be moved from crexec to crcommon.

src/java.base/share/native/libcrexec/environment.hpp line 39:

> 37: char **get_environ();
> 38: 
> 39: class Environment {

I would prefer non-templates to be split into hpp/cpp (at least non-trivial methods) but since this is included just once and we plan to remove crexec anyway I don't insist

src/java.base/share/native/libcrexec/user_data.cpp line 31:

> 29: #include <stdint.h>
> 30: #include <stdlib.h>
> 31: #include <string.h>

Suggestion:

#include <cassert>
#include <cerrno>
#include <cstdio>
#include <cstdint>
#include <cstdlib>
#include <cstring>

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

> 43:     }
> 44: public:
> 45:     UserData(const char **image_location): _image_location(image_location) {}

Suggestion:

    explicit UserData(const char **image_location): _image_location(image_location) {}

src/java.base/share/native/libcrexec/user_data.hpp line 48:

> 46: 
> 47:     bool set_user_data(const char *name, const void *data, size_t size);
> 48:     crlib_user_data_storage_t *load_user_data();

`crlib/crlib_user_data.h` should be included as that is where `crlib_user_data_storage_t` is defined.

src/java.base/share/native/libsimengine/simengine.cpp line 36:

> 34: #endif // LINUX
> 35: 
> 36: #include <new>

Suggestion:

#include <cerrno>
#include <cstring>
#include <cstdio>
#include <cstdlib>
#include <new>
#ifdef LINUX
#include <signal.h>
#include <unistd.h>
#endif // LINUX

src/java.base/share/native/libsimengine/simengine.cpp line 43:

> 41: #include "jni.h"
> 42: 
> 43: #define SIMENGINE "simengine: "

Unused

src/java.base/share/native/libsimengine/simengine.cpp line 68:

> 66: struct SimEngine: public crlib_conf_t {
> 67:   char* _image_location = nullptr;
> 68:   bool _pause;

Suggestion:

  bool _pause = false;

src/java.base/share/native/libsimengine/simengine.cpp line 71:

> 69: 
> 70:   bool _has_restore_data = false;
> 71:   int _restore_data = 0;

I believe we discussed this already at some point, but in my understanding public fields should not have underscores as if this is a plain struct, otherwise they should be private and have a public accessor method when needed.

src/java.base/share/native/libsimengine/simengine.cpp line 99:

> 97:   if (!image_constraints_persist(conf, engine->_image_location) ||
> 98:     !image_score_persist(conf, engine->_image_location)) {
> 99:     return -1;

Suggestion:

  if (!image_constraints_persist(conf, engine->_image_location) ||
      !image_score_persist(conf, engine->_image_location)) {
    return -1;

src/java.base/share/native/libsimengine/simengine.cpp line 141:

> 139:   if (!engine->_pause) {
> 140:     LOG("restore is not supported as a separate action by this engine, "
> 141:         "it always restores a process immediately after checkpointing it");

On Linux this is not true anymore, it should be e.g. "restore is not fully supported by this engine, if you used pause=true option on checkpoint use it again on restore to wake that process up". On Linux the old message should stay until pausing is implemented.

src/java.base/share/native/libsimengine/simengine.cpp line 175:

> 173:   abort(); // engine->_pause should be false
> 174:   return -1;
> 175: #endif LINUX;

Suggestion:

#endif // LINUX;

src/java.base/share/native/libsimengine/simengine.cpp line 179:

> 177: 
> 178: static bool can_configure(crlib_conf_t* conf, const char* key) {
> 179:     return !strcmp(key, opt_image_location) LINUX_ONLY(|| !strcmp(key, opt_pause));

Starting from here and going below the indentation changed from 2 to 4

src/java.base/share/native/libsimengine/simengine.cpp line 255:

> 253:   return
> 254:     "simengine - CRaC-engine used for development & testing; does not implement "
> 255:     "actual process snapshot & rehydration but only simulates these.";

Suggestion:

    "actual process snapshot & restoration but only simulates these.";

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

PR Review: https://git.openjdk.org/crac/pull/289#pullrequestreview-3744787224
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759047695
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759087831
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759080104
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759078508
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759110955
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759189648
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759196998
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759151173
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759210268
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759229132
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759199940
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759242958
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759175708

From tpushkin at openjdk.org  Tue Feb  3 14:06:37 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 14:06:37 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
Message-ID: <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>

On Tue, 3 Feb 2026 09:37:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement static build & other platforms

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

> 67: }
> 68: 
> 69: static bool find_engine(const char *dll_dir, char *path, size_t path_size, bool *is_library, char *resolved_engine, size_t resolved_engine_size) {

This is becoming so complex... With the planned removal of `crexec` it should become simpler but I wonder if we can also simplify it also by deprecating the ability to use both `nameengine` and `name`: allow only `name` that must map to `nameengine.so`? Can be done in a separate PR.

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

> 111:   }
> 112: 
> 113:   if (is_pauseengine()) {

Ideally on Mac `pauseengine` should not be treated specially to preserve the old behavior

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

> 114:     assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
> 115:     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
> 116:     log_warning(crac)("-XX:CRaCEngine=pause/pauseengine is deprecated; use -XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true");

Let's define an obsoletion/expiration version for this. I suggest 28 for both obsoletion and expiration: this way for LTS releases it will be deprecated in April 2026 and obsoleted+expired in April 2027.

Suggestion:

  assert(JDK_Version::current().compare(JDK_Version::jdk(28)) < 0, "pauseengine handling must be removed as obsolete");
  if (is_pauseengine()) {
    assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
    memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
    log_warning(crac)("Option '-XX:CRaCEngine=pauseengine' was deprecated in version 27 and will be removed in version 28. Use options '-XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true' instead.");

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

> 115:     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
> 116:     log_warning(crac)("-XX:CRaCEngine=pause/pauseengine is deprecated; use -XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true");
> 117:   } else if (static_cast<size_t>(os::snprintf(resolved_engine, resolved_engine_size, "%s", CRaCEngine)) >= resolved_engine_size) {

We could move `path_len = strlen(CRaCEngine)` at the very beginning of this function from under if, use it here for the check and use `memcpy` in case of success instead.

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

> 338:   if (!find_engine(dll_dir, path, sizeof(path), &is_library,
> 339:     resolved_engine_func + sizeof(CRLIB_API_FUNC), MAX_ENGINE_LENGTH)) {
> 340:     log_error(crac)("Cannot find CRaC engine %s", CRaCEngine);

Suggestion:

  if (!find_engine(dll_dir, path, sizeof(path), &is_library,
      resolved_engine_func + sizeof(CRLIB_API_FUNC), MAX_ENGINE_LENGTH)) {
    log_error(crac)("Cannot find CRaC engine %s", CRaCEngine);

src/java.base/share/native/libcrcommon/crcommon.hpp line 28:

> 26: #define CRCOMMON_HPP
> 27: 
> 28: #include <stdio.h>

Suggestion:

#include <cstdio>

src/java.base/share/native/libcrcommon/crcommon.hpp line 74:

> 72:   void *_image_constraints;
> 73:   void *_image_score;
> 74: };

Since this is not exposed to C, can't this have the actual classes as field types? Also the fields are not private/protected so no underscores should be used.

Actually, since all users of this is also C++ code compiled by the same compiler, isn't it possible to omit the C API layer of `crcommon`?

src/java.base/share/native/libcrexec/environment.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025,2026, Azul Systems, Inc. All rights reserved.

Suggestion:

 * Copyright (c) 2025, 2026, Azul Systems, Inc. All rights reserved.

src/java.base/share/native/libsimengine/simengine.cpp line 86:

> 84: 
> 85: static crlib_conf_t* create_simengine() {
> 86:     SimEngine *engine = new(std::nothrow) SimEngine();

Neither `init_conf` nor `SimEngine` constructor report any errors ? how are the code and the user supposed to know if something goes wrong there?

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758721973
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759015075
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758659955
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758674949
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758734889
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758838422
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759025361
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758952911
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758813224

From tpushkin at openjdk.org  Tue Feb  3 14:06:39 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 14:06:39 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
Message-ID: <HuGaSdhRZqgF9D_Y97seTSm4Oq3qiujgXqObwjUL-do=.8e5cd525-13d9-4d71-be91-5c76557c338d@github.com>

On Tue, 3 Feb 2026 13:00:18 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement static build & other platforms
>
> src/java.base/share/native/libcrexec/environment.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025,2026, Azul Systems, Inc. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, 2026, Azul Systems, Inc. All rights reserved.

Same in other places with such change

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2758961698

From rvansa at openjdk.org  Tue Feb  3 14:21:53 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 14:21:53 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v4]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <DQ8UV-MlE0Jjp7hRBKqgdxQTrQqGG0loYgpaR2onbPg=.0addccf0-1a1a-41a2-a188-403fe9849d15@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

  Fixup

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/fbd07e66..25961062

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

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

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

From rvansa at openjdk.org  Tue Feb  3 14:33:59 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 14:33:59 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v6]
In-Reply-To: <CvXnPJcMAkOBvgM7xeg2cn47RQEkyqLCOt-QxvmiH-Q=.caaccbbf-4d57-4f4e-9dcb-20718cf70323@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@github.com>
 <PCLYe8mCsx__10QZKIXDLyLY303b8U-9mQcba5jjWgg=.7d7cd5b4-aa31-4374-be40-02b87aff0d5d@github.com>
 <DL3_XNdGMMHZTJ1QfogBVunS8N0oPuSFqwAJ-2Ds0gk=.4a5c2c6e-e637-431b-9e13-5214c36a7ad8@github.com>
 <eOSG0HpfuRk6mmlZkml1pJGbFNZwZjnpLuz4ePDV6UY=.b3d5b083-7f77-43ac-9070-b835ede89179@github.com>
 <CvXnPJcMAkOBvgM7xeg2cn47RQEkyqLCOt-QxvmiH-Q=.caaccbbf-4d57-4f4e-9dcb-20718cf70323@github.com>
Message-ID: <FNDjwHlubEzHmVf7tSO9gwc0Xk0EwXOM35ttzEc4lxg=.bc47db84-6ee1-49c2-9762-181a83010835@github.com>

On Tue, 3 Feb 2026 09:57:42 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> I see, so you just assume that the user will guess the right size, or get an error. I am not saying that you should print a partial bitmap; I think that
>> 
>> if (api->get_failed_bitmap(..., sizeof(image_features)) != sizeof(image_features)) {
>>   // error
>> }
>> 
>> would be an OK implementation. Just worried about cementing a limitation into the API.
>
> IIUC you want to extend the API despite it will have no result on the current JDK functionality. OK, going to implement that.

Thank you :)

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

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

From rvansa at openjdk.org  Tue Feb  3 14:39:29 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 14:39:29 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
Message-ID: <p_sfZnd4uOA2WYkYWr6dGR1YS1k7nUQrquQ90-_iztA=.bf8d5a8c-20eb-4912-b3af-1346936c1a64@github.com>

On Tue, 3 Feb 2026 11:42:21 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement static build & other platforms
>
> src/hotspot/share/runtime/crac_engine.cpp line 116:
> 
>> 114:     assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
>> 115:     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
>> 116:     log_warning(crac)("-XX:CRaCEngine=pause/pauseengine is deprecated; use -XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true");
> 
> Let's define an obsoletion/expiration version for this. I suggest 28 for both obsoletion and expiration: this way for LTS releases it will be deprecated in April 2026 and obsoleted+expired in April 2027.
> 
> Suggestion:
> 
>   assert(JDK_Version::current().compare(JDK_Version::jdk(28)) < 0, "pauseengine handling must be removed as obsolete");
>   if (is_pauseengine()) {
>     assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
>     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
>     log_warning(crac)("Option '-XX:CRaCEngine=pauseengine' was deprecated in version 27 and will be removed in version 28. Use options '-XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true' instead.");

April 2026 is 27, a STS version, and 28 is STS as well (not that it would matter so much in CRaC - we haven't been updating the older branches anyway). I am OK to expire this in 28, though.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759409193

From tpushkin at openjdk.org  Tue Feb  3 14:45:03 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 14:45:03 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <p_sfZnd4uOA2WYkYWr6dGR1YS1k7nUQrquQ90-_iztA=.bf8d5a8c-20eb-4912-b3af-1346936c1a64@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
 <p_sfZnd4uOA2WYkYWr6dGR1YS1k7nUQrquQ90-_iztA=.bf8d5a8c-20eb-4912-b3af-1346936c1a64@github.com>
Message-ID: <yBE0epCURptS9oTwmCG1cYK0C-qm34YvJw2e9nKiluA=.000af4e3-1d0a-4c4c-b671-7d244a1a4ae2@github.com>

On Tue, 3 Feb 2026 14:36:15 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.cpp line 116:
>> 
>>> 114:     assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
>>> 115:     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
>>> 116:     log_warning(crac)("-XX:CRaCEngine=pause/pauseengine is deprecated; use -XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true");
>> 
>> Let's define an obsoletion/expiration version for this. I suggest 28 for both obsoletion and expiration: this way for LTS releases it will be deprecated in April 2026 and obsoleted+expired in April 2027.
>> 
>> Suggestion:
>> 
>>   assert(JDK_Version::current().compare(JDK_Version::jdk(28)) < 0, "pauseengine handling must be removed as obsolete");
>>   if (is_pauseengine()) {
>>     assert(sizeof(SIMENGINE) <= resolved_engine_size, "must be");
>>     memcpy(resolved_engine, SIMENGINE, sizeof(SIMENGINE));
>>     log_warning(crac)("Option '-XX:CRaCEngine=pauseengine' was deprecated in version 27 and will be removed in version 28. Use options '-XX:CRaCEngine=simengine -XX:CRaCEngineOptions=pause=true' instead.");
>
> April 2026 is 27, a STS version, and 28 is STS as well (not that it would matter so much in CRaC - we haven't been updating the older branches anyway). I am OK to expire this in 28, though.

I meant that in OpenJDK we will use 27 for deprecation and 28 for obsoletion, but in our downstream LTS releases we will need to pick versions with the corresponding major versions, otherwise they will never reach the deprecation/obsoletion/expiration. And for that I propose to use the versions that will be released in April 2026 and April 2027.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759437441

From rvansa at openjdk.org  Tue Feb  3 14:48:27 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 14:48:27 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
Message-ID: <zJC-sQgerIgcBDYAPoyYmkoVhI1ZsHATZUE_d9FQ63Y=.aaae04c7-2af0-4c3c-88cb-040de64cd2ee@github.com>

On Tue, 3 Feb 2026 11:58:51 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement static build & other platforms
>
> src/hotspot/share/runtime/crac_engine.cpp line 69:
> 
>> 67: }
>> 68: 
>> 69: static bool find_engine(const char *dll_dir, char *path, size_t path_size, bool *is_library, char *resolved_engine, size_t resolved_engine_size) {
> 
> This is becoming so complex... With the planned removal of `crexec` it should become simpler but I wonder if we can also simplify it also by deprecating the ability to use both `nameengine` and `name`: allow only `name` that must map to `nameengine.so`? Can be done in a separate PR.

Using only `name` means in practice `-XX:CRaCEngine=criu` (now it's `criuengine`), and `-XX:CRaCEngine=sim`. The latter does not sound too descriptive to me :-/
I agree with having `libsimengine.so` in `lib/` - just `libsim.so` would be also a bit confusing, and there's similar name `libsimdsort.so`.
What about deprecating the short names, keeping `-XX:CRaCEngine=criuengine` (current default) and `-XX:CRaCEngine=simengine`? Preferring this long form also works better if there's 3rd engine that does not use the `engine` suffix.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759454118

From tpushkin at openjdk.org  Tue Feb  3 14:55:53 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 14:55:53 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+7
Message-ID: <HkWNEHIHWfVwOjz-tzMh_4LudueK9yUfE8RD_7cDQLQ=.92758609-4074-43a4-9d16-72c80c952dea@github.com>

Merge of mainline up to tag `jdk-27+7`.

Essentially clean, the only conflict was in copyright years. Output of `git show --remerge-diff`:

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 40fea755cf7..27f1c7a8afb 100644
--- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
+++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
@@ -1,12 +1,6 @@
 /*
-<<<<<<< 2f0af59e4d3 (Merge jdk:jdk-27+5)
- * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
-||||||| f6d26c6b32a
- * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
-=======
  * Copyright (c) 2005, 2026, Oracle and/or its affiliates. All rights reserved.
->>>>>>> 62c7e9aefd4 (8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter)
+ * 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

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

Commit messages:
 - Merge jdk:jdk-27+7
 - 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter
 - 8376169: JPopupMenu.setInvoker(null) causes NPE
 - 8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic<T>
 - 8376433: Remove AppContext from Swing Windows L&F implementation
 - 8376434: Remove AppContext from awt ImageFetcher implementation
 - 8376432: Remove AppContext from sun/swing/DefaultLookup.java
 - 8376419: (fs) Minor improvement of java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 - 8376402: Dependencies::print_statistics() and AbstractClassHierarchyWalker::print_statistics() are not called from PRODUCT code
 - 8375433: jar should validate automatic module names
 - ... and 187 more: https://git.openjdk.org/crac/compare/2f0af59e...288267ab

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

Changes: https://git.openjdk.org/crac/pull/290/files
  Stats: 29091 lines in 852 files changed: 13593 ins; 5386 del; 10112 mod
  Patch: https://git.openjdk.org/crac/pull/290.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/290/head:pull/290

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

From rvansa at openjdk.org  Tue Feb  3 14:56:18 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 14:56:18 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
Message-ID: <eoXSYaJNHOHCTWM4ccLG-6OEfKdILaLThQh8IsBpg1M=.a1f951bd-384e-40cd-96d5-cd3ab7e8e8b2@github.com>

On Tue, 3 Feb 2026 13:14:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement static build & other platforms
>
> src/java.base/share/native/libcrcommon/crcommon.hpp line 74:
> 
>> 72:   void *_image_constraints;
>> 73:   void *_image_score;
>> 74: };
> 
> Since this is not exposed to C, can't this have the actual classes as field types? Also the fields are not private/protected so no underscores should be used.
> 
> Actually, since all users of this is also C++ code compiled by the same compiler, isn't it possible to omit the C API layer of `crcommon`?

While probably technically possible (with the same compiler) I don't think it's a good practice to expose C++ ABI across shared libraries. That's why I rather intended this structure as more or less opaque; a little boilerplate aside I don't see downsides.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759491728

From tpushkin at openjdk.org  Tue Feb  3 15:01:11 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 3 Feb 2026 15:01:11 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <zJC-sQgerIgcBDYAPoyYmkoVhI1ZsHATZUE_d9FQ63Y=.aaae04c7-2af0-4c3c-88cb-040de64cd2ee@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
 <zJC-sQgerIgcBDYAPoyYmkoVhI1ZsHATZUE_d9FQ63Y=.aaae04c7-2af0-4c3c-88cb-040de64cd2ee@github.com>
Message-ID: <uuChPK0ZJBNUpMkfOytWSAsTUa3OdeoxpwUU7a3-43c=.144c90cd-29a3-444c-9ced-94faf2060edd@github.com>

On Tue, 3 Feb 2026 14:45:11 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> What about deprecating the short names

OK with me

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759515661

From rvansa at openjdk.org  Tue Feb  3 15:51:44 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 15:51:44 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

Radim Vansa 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/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/25961062..70305b51

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

  Stats: 386 lines in 10 files changed: 159 ins; 115 del; 112 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From rvansa at openjdk.org  Tue Feb  3 15:54:02 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 15:54:02 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <uuChPK0ZJBNUpMkfOytWSAsTUa3OdeoxpwUU7a3-43c=.144c90cd-29a3-444c-9ced-94faf2060edd@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
 <zJC-sQgerIgcBDYAPoyYmkoVhI1ZsHATZUE_d9FQ63Y=.aaae04c7-2af0-4c3c-88cb-040de64cd2ee@github.com>
 <uuChPK0ZJBNUpMkfOytWSAsTUa3OdeoxpwUU7a3-43c=.144c90cd-29a3-444c-9ced-94faf2060edd@github.com>
Message-ID: <JPTl5MMsxRStgRGxSd5UpWQQuMuB5uTqcNWWus4gn04=.8c143bc9-1681-4b94-aa2a-b89ea2362b2a@github.com>

On Tue, 3 Feb 2026 14:58:11 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Using only `name` means in practice `-XX:CRaCEngine=criu` (now it's `criuengine`), and `-XX:CRaCEngine=sim`. The latter does not sound too descriptive to me :-/
>> I agree with having `libsimengine.so` in `lib/` - just `libsim.so` would be also a bit confusing, and there's similar name `libsimdsort.so`.
>> What about deprecating the short names, keeping `-XX:CRaCEngine=criuengine` (current default) and `-XX:CRaCEngine=simengine`? Preferring this long form also works better if there's 3rd engine that does not use the `engine` suffix.
>
>> What about deprecating the short names
> 
> OK with me

Alright; I'll voice the deprecation in the follow-up converting `crexec` into `libcriuengine`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2759756402

From rvansa at openjdk.org  Tue Feb  3 15:57:22 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Feb 2026 15:57:22 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
Message-ID: <m-J_JCw8TMrIFy8wzgq2z6ov-DeooyyNkn6GM_pdjxg=.82bcd4a6-9550-4a51-80e9-2b4f1f8d85d3@github.com>

On Tue, 3 Feb 2026 15:51:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

The point of this PR is not to change `crexec`, that's why I haven't really touched the README. I think that it can be completely removed in the follow-up; I don't see `crcommon` as something that would be exposed externally (and therefore documented).

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3842144896

From jkratochvil at openjdk.org  Tue Feb  3 21:33:19 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 3 Feb 2026 21:33:19 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v8]
In-Reply-To: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <u7rimGLA5U5T090__uhGGsPgM5w8JKvtVx1_UCYcoeE=.00c14ef1-0d60-4a7a-a211-15994f7be9fb@github.com>

> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
> 
> 
> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
> 
> 
> is wrong as it does not do logical and of both CPUFeatures masks.
> 
> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
> 
> @rvansa will probably want to change the API but this is a PoC how it should work.

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

 - Fix the sizeof check
 - get_failed_bitmap: return size_t

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/b447735d..6da16c9b

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

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

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

From jkratochvil at openjdk.org  Tue Feb  3 21:47:11 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 3 Feb 2026 21:47:11 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v9]
In-Reply-To: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <OstoaFP8om0tkE5t3q9HBnhPcCqr4qwulRPFyqBg48c=.74613c9d-83be-43fa-9cda-d8d89c479485@github.com>

> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
> 
> 
> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
> 
> 
> is wrong as it does not do logical and of both CPUFeatures masks.
> 
> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
> 
> @rvansa will probably want to change the API but this is a PoC how it should work.

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

  Revert the check

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/6da16c9b..59a8a4b4

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

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

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

From rvansa at openjdk.org  Wed Feb  4 07:19:26 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Feb 2026 07:19:26 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v6]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <cfBUvJY8stpGPNUpAcxtzUaSdCJyLVmYlb4pLOggXaw=.a4536e63-64cd-4475-8c4e-5cd5549316f6@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

  Try fix Windows build

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/70305b51..756e5bd5

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

  Stats: 21 lines in 3 files changed: 9 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From jkratochvil at openjdk.org  Wed Feb  4 07:48:16 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 4 Feb 2026 07:48:16 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v9]
In-Reply-To: <OstoaFP8om0tkE5t3q9HBnhPcCqr4qwulRPFyqBg48c=.74613c9d-83be-43fa-9cda-d8d89c479485@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <OstoaFP8om0tkE5t3q9HBnhPcCqr4qwulRPFyqBg48c=.74613c9d-83be-43fa-9cda-d8d89c479485@github.com>
Message-ID: <lJCKAVWROi7-zeo9fHOEWfFZG4JoTqapvrhdgkuXQAs=.5132502b-f715-4a8e-bfa3-3d974ef094bd@github.com>

On Tue, 3 Feb 2026 21:47:11 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

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

macros-aarch64 fail is: `jdk/crac/fileDescriptors/ReopenListeningSocketChannelTest.java`
macos-x64 fail is:

The macOS-13 based runner images are now retired. For more details, see https://github.com/actions/runner-images/issues/13046.

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

PR Comment: https://git.openjdk.org/crac/pull/278#issuecomment-3845860598

From tpushkin at openjdk.org  Wed Feb  4 07:52:26 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 4 Feb 2026 07:52:26 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v9]
In-Reply-To: <lJCKAVWROi7-zeo9fHOEWfFZG4JoTqapvrhdgkuXQAs=.5132502b-f715-4a8e-bfa3-3d974ef094bd@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <OstoaFP8om0tkE5t3q9HBnhPcCqr4qwulRPFyqBg48c=.74613c9d-83be-43fa-9cda-d8d89c479485@github.com>
 <lJCKAVWROi7-zeo9fHOEWfFZG4JoTqapvrhdgkuXQAs=.5132502b-f715-4a8e-bfa3-3d974ef094bd@github.com>
Message-ID: <9-g6Q6Qv43l5iW_WwW1zQr1To-Cdf9d2rO313aF8ioA=.e1fd27b5-d0e5-42cf-8668-785aed3d04aa@github.com>

On Wed, 4 Feb 2026 07:45:37 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert the check
>
> macros-aarch64 fail is: `jdk/crac/fileDescriptors/ReopenListeningSocketChannelTest.java`
> macos-x64 fail is:
> 
> The macOS-13 based runner images are now retired. For more details, see https://github.com/actions/runner-images/issues/13046.

@jankratochvil I think you need to update your branch from the target branch. We've recently merged the mainline so the CI issues should be solved.

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

PR Comment: https://git.openjdk.org/crac/pull/278#issuecomment-3845874066

From jkratochvil at openjdk.org  Wed Feb  4 08:27:26 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 4 Feb 2026 08:27:26 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v10]
In-Reply-To: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <YrAA0h31YqWKhjq5S9NugoHBoOiJIjW4Ep2dIWMUHzY=.4a7daed3-fe72-4888-9a13-837d59f77ce1@github.com>

> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
> 
> 
> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
> 
> 
> is wrong as it does not do logical and of both CPUFeatures masks.
> 
> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
> 
> @rvansa will probably want to change the API but this is a PoC how it should work.

Jan Kratochvil has updated the pull request 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 16 additional commits since the last revision:

 - Merge branch 'crac' into crac-conjunction
 - Revert the check
 - Fix the sizeof check
 - get_failed_bitmap: return size_t
 - Use current_features everywhere
 - Fix "try using -XX:CPUFeatures" for the 'exact' case.
 - Check for failed malloc
 - Fix non-x86 builds
 - get_failed_bitmap to return stored data
 - Merge branch 'crac' into crac-conjunction
 - ... and 6 more: https://git.openjdk.org/crac/compare/780c06e1...d27c0e7a

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/59a8a4b4..d27c0e7a

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

  Stats: 825701 lines in 10640 files changed: 544360 ins; 173424 del; 107917 mod
  Patch: https://git.openjdk.org/crac/pull/278.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/278/head:pull/278

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

From rvansa at openjdk.org  Wed Feb  4 10:16:47 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Feb 2026 10:16:47 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v7]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <BVWC0_h-tczy0yiX3lELD0dbflaCqW927Pri1QKacFE=.c8968bca-ee1a-4438-a96c-8b1eacd09dcb@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

  Fix tests on non-Linux

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/756e5bd5..801fc70b

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

  Stats: 27 lines in 2 files changed: 12 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From rvansa at openjdk.org  Wed Feb  4 11:49:09 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Feb 2026 11:49:09 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+7
In-Reply-To: <HkWNEHIHWfVwOjz-tzMh_4LudueK9yUfE8RD_7cDQLQ=.92758609-4074-43a4-9d16-72c80c952dea@github.com>
References: <HkWNEHIHWfVwOjz-tzMh_4LudueK9yUfE8RD_7cDQLQ=.92758609-4074-43a4-9d16-72c80c952dea@github.com>
Message-ID: <sxSF-Cs4Qk5kZdLqekgsGSi8xsxMrPkKegd2nY5rJFI=.a3910b15-8ce1-4a03-b8ed-7cebdb44a48b@github.com>

On Tue, 3 Feb 2026 14:49:43 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Merge of mainline up to tag `jdk-27+7`.
> 
> Essentially clean, the only conflict was in copyright years. Output of `git show --remerge-diff`:
> 
> 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 40fea755cf7..27f1c7a8afb 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,12 +1,6 @@
>  /*
> -<<<<<<< 2f0af59e4d3 (Merge jdk:jdk-27+5)
> - * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -||||||| f6d26c6b32a
> - * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2026, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 62c7e9aefd4 (8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter)
> + * 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

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/290#pullrequestreview-3750582385

From rvansa at openjdk.org  Wed Feb  4 11:52:27 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Feb 2026 11:52:27 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v10]
In-Reply-To: <YrAA0h31YqWKhjq5S9NugoHBoOiJIjW4Ep2dIWMUHzY=.4a7daed3-fe72-4888-9a13-837d59f77ce1@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <YrAA0h31YqWKhjq5S9NugoHBoOiJIjW4Ep2dIWMUHzY=.4a7daed3-fe72-4888-9a13-837d59f77ce1@github.com>
Message-ID: <rj_F1og5qab9zIf2nlsLgGcoygVzO111IMvvP70MhJ8=.22b79e84-4e64-477e-8842-c89592d58eb6@github.com>

On Wed, 4 Feb 2026 08:27:26 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
>> 
>> 
>> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
>> 
>> 
>> is wrong as it does not do logical and of both CPUFeatures masks.
>> 
>> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
>> 
>> @rvansa will probably want to change the API but this is a PoC how it should work.
>
> Jan Kratochvil has updated the pull request 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 16 additional commits since the last revision:
> 
>  - Merge branch 'crac' into crac-conjunction
>  - Revert the check
>  - Fix the sizeof check
>  - get_failed_bitmap: return size_t
>  - Use current_features everywhere
>  - Fix "try using -XX:CPUFeatures" for the 'exact' case.
>  - Check for failed malloc
>  - Fix non-x86 builds
>  - get_failed_bitmap to return stored data
>  - Merge branch 'crac' into crac-conjunction
>  - ... and 6 more: https://git.openjdk.org/crac/compare/dbaf6cfe...d27c0e7a

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/278#pullrequestreview-3750598483

From tpushkin at openjdk.org  Wed Feb  4 11:55:57 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 4 Feb 2026 11:55:57 GMT
Subject: [crac] Integrated: Merge jdk:jdk-27+7
In-Reply-To: <HkWNEHIHWfVwOjz-tzMh_4LudueK9yUfE8RD_7cDQLQ=.92758609-4074-43a4-9d16-72c80c952dea@github.com>
References: <HkWNEHIHWfVwOjz-tzMh_4LudueK9yUfE8RD_7cDQLQ=.92758609-4074-43a4-9d16-72c80c952dea@github.com>
Message-ID: <XwrPDOb7hXPqBHvc_kX-M6-a7TzPOyo380-bW862vs4=.b0b881a0-336b-48d8-990a-a77cf897040e@github.com>

On Tue, 3 Feb 2026 14:49:43 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Merge of mainline up to tag `jdk-27+7`.
> 
> Essentially clean, the only conflict was in copyright years. Output of `git show --remerge-diff`:
> 
> 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 40fea755cf7..27f1c7a8afb 100644
> --- a/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> +++ b/src/hotspot/share/gc/parallel/psParallelCompact.cpp
> @@ -1,12 +1,6 @@
>  /*
> -<<<<<<< 2f0af59e4d3 (Merge jdk:jdk-27+5)
> - * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2019, 2021, Azul Systems, Inc. All rights reserved.
> -||||||| f6d26c6b32a
> - * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved.
> -=======
>   * Copyright (c) 2005, 2026, Oracle and/or its affiliates. All rights reserved.
> ->>>>>>> 62c7e9aefd4 (8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter)
> + * 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

This pull request has now been integrated.

Changeset: 03b55647
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/03b556479e69acf06610a671c342a3b900ed2a0f
Stats:     29091 lines in 852 files changed: 13593 ins; 5386 del; 10112 mod

Merge jdk:jdk-27+7

Reviewed-by: rvansa

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

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

From duke at openjdk.org  Wed Feb  4 12:04:28 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 12:04:28 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v10]
In-Reply-To: <YrAA0h31YqWKhjq5S9NugoHBoOiJIjW4Ep2dIWMUHzY=.4a7daed3-fe72-4888-9a13-837d59f77ce1@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <YrAA0h31YqWKhjq5S9NugoHBoOiJIjW4Ep2dIWMUHzY=.4a7daed3-fe72-4888-9a13-837d59f77ce1@github.com>
Message-ID: <nLwqZNvcPveDdhQxM7R8z7OasdBCKDG5mwDH4y42GXk=.26f0659d-902f-4fd2-ba35-3fef85b71d44@github.com>

On Wed, 4 Feb 2026 08:27:26 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
>> 
>> 
>> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
>> 
>> 
>> is wrong as it does not do logical and of both CPUFeatures masks.
>> 
>> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
>> 
>> @rvansa will probably want to change the API but this is a PoC how it should work.
>
> Jan Kratochvil has updated the pull request 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 16 additional commits since the last revision:
> 
>  - Merge branch 'crac' into crac-conjunction
>  - Revert the check
>  - Fix the sizeof check
>  - get_failed_bitmap: return size_t
>  - Use current_features everywhere
>  - Fix "try using -XX:CPUFeatures" for the 'exact' case.
>  - Check for failed malloc
>  - Fix non-x86 builds
>  - get_failed_bitmap to return stored data
>  - Merge branch 'crac' into crac-conjunction
>  - ... and 6 more: https://git.openjdk.org/crac/compare/c37166d4...d27c0e7a

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

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

PR Comment: https://git.openjdk.org/crac/pull/278#issuecomment-3847035970

From jkratochvil at openjdk.org  Wed Feb  4 12:07:55 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 4 Feb 2026 12:07:55 GMT
Subject: [crac] Integrated: 8372933: [CRaC] Restore failed due to incompatible
 or missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint
In-Reply-To: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <1sOK5dhxWR__9wTbdgr8-MAtzu4teNvTXEsAT8A-w0s=.9127ad3f-257e-437e-a255-e21f06145d26@github.com>

On Tue, 2 Dec 2025 13:22:18 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message:
> 
> 
> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint.
> 
> 
> is wrong as it does not do logical and of both CPUFeatures masks.
> 
> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review.
> 
> @rvansa will probably want to change the API but this is a PoC how it should work.

This pull request has now been integrated.

Changeset: 4a940b79
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/4a940b794d482a9d0d2d7db5c88e848199d36eec
Stats:     80 lines in 9 files changed: 58 ins; 0 del; 22 mod

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

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Wed Feb  4 15:35:25 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Feb 2026 15:35:25 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

 - Merge branch 'crac' into simengine_separation
 - Fix tests on non-Linux
 - Try fix Windows build
 - Address review comments
 - Fixup
 - Fixups
 - Implement static build & other platforms
 - JDK-8376959: [CRaC] Turn simengine into shared library

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

Changes: https://git.openjdk.org/crac/pull/289/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=289&range=07
  Stats: 3003 lines in 27 files changed: 1753 ins; 1172 del; 78 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From rvansa at openjdk.org  Thu Feb  5 06:52:53 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 06:52:53 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v3]
In-Reply-To: <_7JmXVhjoER_fwXg3kyWl2la05FqWO1PG60Bk4V5Tqs=.b5ed45c9-d0a5-4a4b-ac57-944b18b1d1b1@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <mozUa47N3xVmEbb0rgwpVcbfA9hrq0akdHGrO3UEA88=.c16973eb-b80c-4f01-953a-d7c24919e676@github.com>
 <_7JmXVhjoER_fwXg3kyWl2la05FqWO1PG60Bk4V5Tqs=.b5ed45c9-d0a5-4a4b-ac57-944b18b1d1b1@github.com>
Message-ID: <xvImwg7NUoffPLkPaXDjQDGCYZb3WiZpxlVY20TSk9Y=.9ab7609e-2596-4054-b46c-b874dec0bcf9@github.com>

On Tue, 3 Feb 2026 14:03:05 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixups
>
> I skipped most of crexec changes since we plan to remove it soon.
> 
> Looks like the README should now be moved from crexec to crcommon.

@TimPushkin I got the other platforms passing, please re-check.

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3851387625

From tpushkin at openjdk.org  Thu Feb  5 06:52:55 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 06:52:55 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
Message-ID: <ry9PaCpuzB8-Nh5riB3oYeu2cL4bq4I7rlCIXh8OlTc=.1880a7f4-cf59-4749-ad79-b019338d419a@github.com>

On Wed, 4 Feb 2026 15:35:25 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'crac' into simengine_separation
>  - Fix tests on non-Linux
>  - Try fix Windows build
>  - Address review comments
>  - Fixup
>  - Fixups
>  - Implement static build & other platforms
>  - JDK-8376959: [CRaC] Turn simengine into shared library

Thanks, I plan to early next week

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3851394504

From rvansa at openjdk.org  Thu Feb  5 06:59:35 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 06:59:35 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
Message-ID: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>

If possible, test should use simengine.
If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.

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

Commit messages:
 - Imports cleanup
 - 8377177: [CRaC] Clarify engine use in the testsuite

Changes: https://git.openjdk.org/crac/pull/291/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=291&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377177
  Stats: 202 lines in 30 files changed: 90 ins; 78 del; 34 mod
  Patch: https://git.openjdk.org/crac/pull/291.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/291/head:pull/291

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

From rvansa at openjdk.org  Thu Feb  5 07:24:19 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 07:24:19 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on checkpoint
Message-ID: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>

This is a restore-only option, sanity check in the engine might produce warnings/errors.

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

Commit messages:
 - 8377173: [CRaC] Don't set direct_map=true on checkpoint

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

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

From tpushkin at openjdk.org  Thu Feb  5 09:37:35 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 09:37:35 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint
In-Reply-To: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
Message-ID: <-cwPt7u4njs5NzVFrLIiWaF041VEiTR8vtCRLbyc8MA=.5fa3a8d1-0076-439f-be04-e1be1ec897dc@github.com>

On Thu, 5 Feb 2026 07:16:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This is a restore-only option, sanity check in the engine might produce warnings/errors.

LGTM but I have a suggestion

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

> 183:   }
> 184: 
> 185:   if (for_restore && api.can_configure(conf, DIRECT_MAP)) {

We have `CStringSet keys` below that stores all options parsed from `CRaCEngineOptions`. We could move this after the `CRaCEngineOptions` processing to apply only if `DIRECT_MAP` was not in `CRaCEngineOptions`. This way we can avoid providing the option twice ? can help against warnings if the engine also performs duplication checking internally.

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

PR Review: https://git.openjdk.org/crac/pull/292#pullrequestreview-3755619560
PR Review Comment: https://git.openjdk.org/crac/pull/292#discussion_r2767983044

From rvansa at openjdk.org  Thu Feb  5 09:56:43 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 09:56:43 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
 [v2]
In-Reply-To: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
Message-ID: <72NLJ69QftI5C5Bix3Q6g8ZOJGIXn0Kiy8vrXMujoiY=.370bcadb-7c0c-4a95-920d-8809b48fdbb4@github.com>

> If possible, test should use simengine.
> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.

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

  Assert number of CracTest arguments

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

Changes:
  - all: https://git.openjdk.org/crac/pull/291/files
  - new: https://git.openjdk.org/crac/pull/291/files/5d372439..9f7bb258

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

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

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

From rvansa at openjdk.org  Thu Feb  5 11:06:49 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 11:06:49 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint [v2]
In-Reply-To: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
Message-ID: <7DndEU1yB7Y_b2dWz5V_pQyYN98QMl8BcMo3vl_HmfU=.afaeae45-c504-48af-acb2-260953165459@github.com>

> This is a restore-only option, sanity check in the engine might produce warnings/errors.

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

  Avoid configuring direct_map twice

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

Changes:
  - all: https://git.openjdk.org/crac/pull/292/files
  - new: https://git.openjdk.org/crac/pull/292/files/8e25a155..13d3e26f

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

  Stats: 53 lines in 1 file changed: 16 ins; 16 del; 21 mod
  Patch: https://git.openjdk.org/crac/pull/292.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/292/head:pull/292

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

From rvansa at openjdk.org  Thu Feb  5 11:06:51 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 11:06:51 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint [v2]
In-Reply-To: <-cwPt7u4njs5NzVFrLIiWaF041VEiTR8vtCRLbyc8MA=.5fa3a8d1-0076-439f-be04-e1be1ec897dc@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
 <-cwPt7u4njs5NzVFrLIiWaF041VEiTR8vtCRLbyc8MA=.5fa3a8d1-0076-439f-be04-e1be1ec897dc@github.com>
Message-ID: <jejqKvw9l-GDhB5l8ixV1lgHsfvUvIk9EQMpVp1i30I=.a8476e1b-0eb0-4814-9cb4-94bb2420a444@github.com>

On Thu, 5 Feb 2026 09:33:52 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid configuring direct_map twice
>
> src/hotspot/share/runtime/crac_engine.cpp line 185:
> 
>> 183:   }
>> 184: 
>> 185:   if (for_restore && api.can_configure(conf, DIRECT_MAP)) {
> 
> We have `CStringSet keys` below that stores all options parsed from `CRaCEngineOptions`. We could move this after the `CRaCEngineOptions` processing to apply only if `DIRECT_MAP` was not in `CRaCEngineOptions`. This way we can avoid providing the option twice ? can help against warnings if the engine also performs duplication checking internally.

I've moved this, though the change is a bit heavier (can't use the early exit). And I am not even sure if the engine ought to check this - it should be OK to override the configuration couple of times.

I'd be happy to revert the last commit if you see it the same way.

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

PR Review Comment: https://git.openjdk.org/crac/pull/292#discussion_r2768440744

From tpushkin at openjdk.org  Thu Feb  5 11:24:32 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 11:24:32 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint [v2]
In-Reply-To: <7DndEU1yB7Y_b2dWz5V_pQyYN98QMl8BcMo3vl_HmfU=.afaeae45-c504-48af-acb2-260953165459@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
 <7DndEU1yB7Y_b2dWz5V_pQyYN98QMl8BcMo3vl_HmfU=.afaeae45-c504-48af-acb2-260953165459@github.com>
Message-ID: <A7hC9UCdBAx8R0fgsv8X-c5zQJ0Y7Je9kiJpwmbob-E=.0cc77715-0a3c-4767-8937-0028201ddd73@github.com>

On Thu, 5 Feb 2026 11:06:49 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This is a restore-only option, sanity check in the engine might produce warnings/errors.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid configuring direct_map twice

Marked as reviewed by tpushkin (Committer).

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

> 184: 
> 185:   CStringSet keys;
> 186:   char* engine_options_start = nullptr;

Does not match the style of the rest of the file, but I don't insist on fixing not to wait more for CI.
Suggestion:

  char *engine_options_start = nullptr;

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

PR Review: https://git.openjdk.org/crac/pull/292#pullrequestreview-3756348744
PR Review Comment: https://git.openjdk.org/crac/pull/292#discussion_r2768539941

From tpushkin at openjdk.org  Thu Feb  5 11:24:35 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 11:24:35 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint [v2]
In-Reply-To: <jejqKvw9l-GDhB5l8ixV1lgHsfvUvIk9EQMpVp1i30I=.a8476e1b-0eb0-4814-9cb4-94bb2420a444@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
 <-cwPt7u4njs5NzVFrLIiWaF041VEiTR8vtCRLbyc8MA=.5fa3a8d1-0076-439f-be04-e1be1ec897dc@github.com>
 <jejqKvw9l-GDhB5l8ixV1lgHsfvUvIk9EQMpVp1i30I=.a8476e1b-0eb0-4814-9cb4-94bb2420a444@github.com>
Message-ID: <6U9Qp9Yon8Ti5h3asTthNwGorOV-Wcrs-I9oQ1p4y6c=.17d5811d-60ea-4326-8d5f-89a971d76a6e@github.com>

On Thu, 5 Feb 2026 11:03:37 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.cpp line 185:
>> 
>>> 183:   }
>>> 184: 
>>> 185:   if (for_restore && api.can_configure(conf, DIRECT_MAP)) {
>> 
>> We have `CStringSet keys` below that stores all options parsed from `CRaCEngineOptions`. We could move this after the `CRaCEngineOptions` processing to apply only if `DIRECT_MAP` was not in `CRaCEngineOptions`. This way we can avoid providing the option twice ? can help against warnings if the engine also performs duplication checking internally.
>
> I've moved this, though the change is a bit heavier (can't use the early exit). And I am not even sure if the engine ought to check this - it should be OK to override the configuration couple of times.
> 
> I'd be happy to revert the last commit if you see it the same way.

I expected that the early return would need to go, looks fine by me. Just suggested this to omit doing redundant work.

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

PR Review Comment: https://git.openjdk.org/crac/pull/292#discussion_r2768530287

From rvansa at openjdk.org  Thu Feb  5 11:58:13 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 11:58:13 GMT
Subject: [crac] RFR: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint [v2]
In-Reply-To: <A7hC9UCdBAx8R0fgsv8X-c5zQJ0Y7Je9kiJpwmbob-E=.0cc77715-0a3c-4767-8937-0028201ddd73@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
 <7DndEU1yB7Y_b2dWz5V_pQyYN98QMl8BcMo3vl_HmfU=.afaeae45-c504-48af-acb2-260953165459@github.com>
 <A7hC9UCdBAx8R0fgsv8X-c5zQJ0Y7Je9kiJpwmbob-E=.0cc77715-0a3c-4767-8937-0028201ddd73@github.com>
Message-ID: <AUPo3abOsCgQFBYGWJEx-lQvzgDcDn3qkDdE5rShTjI=.7eef23c8-d237-4e39-9081-dda918b61d17@github.com>

On Thu, 5 Feb 2026 11:21:53 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid configuring direct_map twice
>
> src/hotspot/share/runtime/crac_engine.cpp line 186:
> 
>> 184: 
>> 185:   CStringSet keys;
>> 186:   char* engine_options_start = nullptr;
> 
> Does not match the style of the rest of the file, but I don't insist on fixing not to wait more for CI.
> Suggestion:
> 
>   char *engine_options_start = nullptr;

While my personal preference is `char *`, we shall probably prefer the style the rest of JDK uses - I took the opportunity.
(I was asked to change the style when filing PRs to upstream)

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

PR Review Comment: https://git.openjdk.org/crac/pull/292#discussion_r2768730787

From tpushkin at openjdk.org  Thu Feb  5 12:27:43 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 12:27:43 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
 [v2]
In-Reply-To: <72NLJ69QftI5C5Bix3Q6g8ZOJGIXn0Kiy8vrXMujoiY=.370bcadb-7c0c-4a95-920d-8809b48fdbb4@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
 <72NLJ69QftI5C5Bix3Q6g8ZOJGIXn0Kiy8vrXMujoiY=.370bcadb-7c0c-4a95-920d-8809b48fdbb4@github.com>
Message-ID: <H9k-K3XMMUvJyIsmN7szxOPzWe4e_rE8mLFgKFhs9gA=.65d86fba-ea3c-405f-a2ee-8a413762a630@github.com>

On Thu, 5 Feb 2026 09:56:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> If possible, test should use simengine.
>> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
>> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assert number of CracTest arguments

Could you please document the policy as the doc of `engine(...)` method? Probably worth noting that the default is guaranteed to be some "real" engine (but not necessarily CRIU).

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

PR Review: https://git.openjdk.org/crac/pull/291#pullrequestreview-3756799722

From rvansa at openjdk.org  Thu Feb  5 13:55:24 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 13:55:24 GMT
Subject: [crac] Integrated: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint
In-Reply-To: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
References: <YhF_wQOSj51bkm9a9J7qB8AEpo0nuFmnvIZb6Wt9BUc=.b597cdc6-5a28-4fcd-a583-8d5b5ea23518@github.com>
Message-ID: <yC6PAs0k7YUK3BpFFJuyMXpYl66W2aFRUOphgflxAWI=.3807f471-751f-4747-86bd-ef4d089c447a@github.com>

On Thu, 5 Feb 2026 07:16:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This is a restore-only option, sanity check in the engine might produce warnings/errors.

This pull request has now been integrated.

Changeset: 094b70a4
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/094b70a463c2a7ed2f619100d16e1b03173bee67
Stats:     60 lines in 3 files changed: 16 ins; 16 del; 28 mod

8377173: [CRaC] Don't set direct_map=true on checkpoint

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Thu Feb  5 13:59:48 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 13:59:48 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <m-J_JCw8TMrIFy8wzgq2z6ov-DeooyyNkn6GM_pdjxg=.82bcd4a6-9550-4a51-80e9-2b4f1f8d85d3@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
 <m-J_JCw8TMrIFy8wzgq2z6ov-DeooyyNkn6GM_pdjxg=.82bcd4a6-9550-4a51-80e9-2b4f1f8d85d3@github.com>
Message-ID: <LAJ3inBVPi2lt2ch5iwZBTMReED_y_DxWAWzAbd1HVg=.f4409115-830b-4e8c-a07b-2e3d1228714d@github.com>

On Tue, 3 Feb 2026 15:54:37 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> The point of this PR is not to change crexec, that's why I haven't really touched the README. I think that it can be completely removed in the follow-up

We added the doc because otherwise the format of saved scores is not documented anywhere. I am OK with addressing this in the PR that will remove crexec but the doc should be retained in some place common for engines that use crcommon.

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3853829420

From rvansa at openjdk.org  Thu Feb  5 14:06:40 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 14:06:40 GMT
Subject: git: openjdk/crac: crac: 8377173: [CRaC] Don't set direct_map=true on
 checkpoint
Message-ID: <2cd97c6b-6106-4eb0-bc25-2035aa949068@openjdk.org>

Changeset: 094b70a4
Branch: crac
Author:    Radim Vansa <rvansa at openjdk.org>
Date:      2026-02-05 13:52:45 +0000
URL:       https://git.openjdk.org/crac/commit/094b70a463c2a7ed2f619100d16e1b03173bee67

8377173: [CRaC] Don't set direct_map=true on checkpoint

Reviewed-by: tpushkin

! src/hotspot/share/runtime/crac.cpp
! src/hotspot/share/runtime/crac_engine.cpp
! src/hotspot/share/runtime/crac_engine.hpp


From snazarki at openjdk.org  Thu Feb  5 14:10:57 2026
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Thu, 5 Feb 2026 14:10:57 GMT
Subject: [crac] RFR: 8362238: [CRaC] crac/fileDescriptors/FileWatcherThreadTest
 should wait for events with timeout
Message-ID: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>

test/jdk/jdk/crac/fileDescriptors/FileWatcherThreadTest.java may be affected by race condition. Particularly case with checkpointWithoutKey=false may wait infinite temporary file is created before WatchKey is acquired. Since the bug is never reproduced locally I suggest to fix step-by-step. Let?s introduce timeout case firstly.

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

Commit messages:
 - 8362238: [CRaC] crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout

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

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

From tpushkin at openjdk.org  Thu Feb  5 14:18:22 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 14:18:22 GMT
Subject: [crac] RFR: 8362238: [CRaC]
 crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout
In-Reply-To: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
References: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
Message-ID: <fbZ-PcE-Ev1L6JIfJCET69Ba4iGkMlpZVCADATLiRx8=.400a6ca7-9c97-4dc1-b11d-cae8f56659a2@github.com>

On Thu, 5 Feb 2026 14:04:10 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> test/jdk/jdk/crac/fileDescriptors/FileWatcherThreadTest.java may be affected by race condition. Particularly case with checkpointWithoutKey=false may wait infinite temporary file is created before WatchKey is acquired. Since the bug is never reproduced locally I suggest to fix step-by-step. Let?s introduce timeout case firstly.

@snazarkin Could you please enable GitHub Actions in your fork so that we can ensure the tests don't start failing for some reason? You'll probably also need to add an empty commit for the CI to start.

Ah, ignore that, it just took 10 minutes for the tests to show up

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

PR Comment: https://git.openjdk.org/crac/pull/293#issuecomment-3853949394
PR Comment: https://git.openjdk.org/crac/pull/293#issuecomment-3853959242

From rvansa at openjdk.org  Thu Feb  5 15:21:57 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 15:21:57 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
 [v3]
In-Reply-To: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
Message-ID: <U6cKKeYyqHYZQU2zMe4HYM_oSY6vk2R-C8w09s2Za-s=.71d1d9d2-1aaf-4f70-bcad-c0f39d2f4a72@github.com>

> If possible, test should use simengine.
> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.

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

  Add docs

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

Changes:
  - all: https://git.openjdk.org/crac/pull/291/files
  - new: https://git.openjdk.org/crac/pull/291/files/9f7bb258..c8f67b1e

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

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

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

From tpushkin at openjdk.org  Thu Feb  5 15:50:10 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 15:50:10 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
 [v3]
In-Reply-To: <U6cKKeYyqHYZQU2zMe4HYM_oSY6vk2R-C8w09s2Za-s=.71d1d9d2-1aaf-4f70-bcad-c0f39d2f4a72@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
 <U6cKKeYyqHYZQU2zMe4HYM_oSY6vk2R-C8w09s2Za-s=.71d1d9d2-1aaf-4f70-bcad-c0f39d2f4a72@github.com>
Message-ID: <09zDmZuFyg4G073wobEHUm_QMDwXbjnAMMez_0_7cL0=.52a71d57-bd32-4608-976f-66ce78550574@github.com>

On Thu, 5 Feb 2026 15:21:57 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> If possible, test should use simengine.
>> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
>> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add docs

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/291#pullrequestreview-3757938112

From tpushkin at openjdk.org  Thu Feb  5 15:51:18 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 5 Feb 2026 15:51:18 GMT
Subject: [crac] RFR: 8362238: [CRaC]
 crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout
In-Reply-To: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
References: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
Message-ID: <lHpCe9Viie9EbVKlUpFAZtvXEbp9yDsxnPmLep6RNNM=.4b09fca3-056d-4d49-bc8d-618045011abe@github.com>

On Thu, 5 Feb 2026 14:04:10 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> test/jdk/jdk/crac/fileDescriptors/FileWatcherThreadTest.java may be affected by race condition. Particularly case with checkpointWithoutKey=false may wait infinite temporary file is created before WatchKey is acquired. Since the bug is never reproduced locally I suggest to fix step-by-step. Let?s introduce timeout case firstly.

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/293#pullrequestreview-3757940093

From rvansa at openjdk.org  Thu Feb  5 20:08:47 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 20:08:47 GMT
Subject: [crac] RFR: 8377177: [CRaC] Clarify engine use in the testsuite
 [v3]
In-Reply-To: <U6cKKeYyqHYZQU2zMe4HYM_oSY6vk2R-C8w09s2Za-s=.71d1d9d2-1aaf-4f70-bcad-c0f39d2f4a72@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
 <U6cKKeYyqHYZQU2zMe4HYM_oSY6vk2R-C8w09s2Za-s=.71d1d9d2-1aaf-4f70-bcad-c0f39d2f4a72@github.com>
Message-ID: <6lAARAj6cWkjVnEjwhsQ4am0jw_LGG-QXpnStuAco0A=.b2a189e7-cb5f-4cbf-8bcf-e3c8ff3f537c@github.com>

On Thu, 5 Feb 2026 15:21:57 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> If possible, test should use simengine.
>> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
>> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add docs

Test failure in `JdwpTransportTest` is recurrent, not related.

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

PR Comment: https://git.openjdk.org/crac/pull/291#issuecomment-3855930268

From rvansa at openjdk.org  Thu Feb  5 20:08:49 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Feb 2026 20:08:49 GMT
Subject: [crac] Integrated: 8377177: [CRaC] Clarify engine use in the testsuite
In-Reply-To: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
References: <qtI-pPlB0bgi9ykLpeJTpG-pLPX2J0uW3I0SmGsG3CQ=.7540f79a-817e-477b-8df7-5466de721495@github.com>
Message-ID: <ahCp0DzqkI2WqjthqZrzBH5qTG0-s0Z2hxpk8DjxD8k=.1fbc94c8-f20c-4132-a05e-3111efddd9ff@github.com>

On Thu, 5 Feb 2026 06:52:42 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> If possible, test should use simengine.
> If the test is specific to engine behaviour, it should use CracBuilder.engine(...) explicitly.
> If the test can cover more generic behaviour of real engines, either use the default or accept the engine as test arg.

This pull request has now been integrated.

Changeset: b458a418
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/b458a4181ef98ff4a2743d2889d6c164a8d0eee3
Stats:     218 lines in 32 files changed: 106 ins; 78 del; 34 mod

8377177: [CRaC] Clarify engine use in the testsuite

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Fri Feb  6 08:45:04 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 6 Feb 2026 08:45:04 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
Message-ID: <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>

On Wed, 4 Feb 2026 15:35:25 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'crac' into simengine_separation
>  - Fix tests on non-Linux
>  - Try fix Windows build
>  - Address review comments
>  - Fixup
>  - Fixups
>  - Implement static build & other platforms
>  - JDK-8376959: [CRaC] Turn simengine into shared library

Please don't forget https://github.com/openjdk/crac/pull/289#discussion_r2758659955

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

> 248:       return nullptr;
> 249:     }
> 250:   }

Should be under `#ifdef LINUX`, `is_pauseengine` itself could be as well

src/java.base/share/native/libcrcommon/crcommon.cpp line 27:

> 25: #include "crcommon.hpp"
> 26: 
> 27: #include "image_constraints.hpp"

`crlib*` headers should be included since they are used directly

src/java.base/share/native/libcrcommon/crcommon.cpp line 63:

> 61: 
> 62: JNIEXPORT bool init_conf(struct crlib_conf* conf, const char* prefix) {
> 63:     log_prefix = prefix;

Indent should be 2, in `destroy_conf` as well

src/java.base/share/native/libcrcommon/crcommon.hpp line 74:

> 72:   void *image_constraints;
> 73:   void *image_score;
> 74: };

Since we want to use the C layer a more conventional way seems to be to move this definition to `crcommon.cpp` (it can even become a normal class with a constructor/destructor) and use composition instead of inheritance (engine classes would be `struct crlib_conf`s themselves, `bool init_conf(conf_t* conf, ...)` would become `conf_t* create_conf(...)`). These fields are not used directly anywhere except `crcommon.cpp` anyway.

Otherwise the fields can at least become their actual types to remove the casts in `crcommon.cpp`.

src/java.base/share/native/libcrcommon/crcommon.hpp line 83:

> 81: 
> 82: extern "C" {
> 83:   extern CRCOMMON_API const char* log_prefix;

Nitpick: this looks like it should be a part of `crlib_conf_t`. `LOG` can accept `conf` as parameter ? does not seem too bulky. If the conf will be an opaque type then ` const char* log_prefix(const crlib_conf*)` will also be needed.

src/java.base/share/native/libcrcommon/crcommon.hpp line 85:

> 83:   extern CRCOMMON_API const char* log_prefix;
> 84: 
> 85:   extern CRCOMMON_API bool init_conf(struct crlib_conf* conf, const char* log_prefix);

`crlib_conf_t` can be used instead of `struct crlib_conf`. It is not only in this file.

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

PR Review: https://git.openjdk.org/crac/pull/289#pullrequestreview-3757660401
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2769626562
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772944143
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772899159
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772861394
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772891014
PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772894519

From tpushkin at openjdk.org  Fri Feb  6 08:45:07 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 6 Feb 2026 08:45:07 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
Message-ID: <I4Y-7dHQ8V8zdddM7gUiaQt7PEdbQrxLJtTXVtbj65o=.3bc16eef-ae14-4969-a5ee-b8efecd7ef9e@github.com>

On Tue, 3 Feb 2026 15:51:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
>> 
>> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
>> 
>> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

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

> 294:   auto * const conf = new(std::nothrow) CrExec();
> 295:   if (conf == nullptr || !conf->is_initialized()) {
> 296:     LOG("Cannot create crexec instance (insufficient memory?)");

Nitpick: both here and in simengine we know whether it was insufficient memory (`conf == nullptr`) or something else (`!conf->is_initialized()`). `!conf->is_initialized()` can also be caused by insufficient memory but that is up to `CrExec`'s constructor to log. So I believe the best way would be: `if (conf == nullptr) LOG("insufficient memory")`

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2772672222

From duke at openjdk.org  Fri Feb  6 10:49:44 2026
From: duke at openjdk.org (duke)
Date: Fri, 6 Feb 2026 10:49:44 GMT
Subject: [crac] RFR: 8362238: [CRaC]
 crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout
In-Reply-To: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
References: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
Message-ID: <HhZV-wBVFtW58mGndiFXkpnP-JnRbQH4qIsJWxVxVKc=.b135fbfd-8223-4a1a-9511-9a3c7c419161@github.com>

On Thu, 5 Feb 2026 14:04:10 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> test/jdk/jdk/crac/fileDescriptors/FileWatcherThreadTest.java may be affected by race condition. Particularly case with checkpointWithoutKey=false may wait infinite temporary file is created before WatchKey is acquired. Since the bug is never reproduced locally I suggest to fix step-by-step. Let?s introduce timeout case firstly.

@snazarkin 
Your change (at version 4af98b991bdb5d0f82c2d566e947015bbffdc56f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/crac/pull/293#issuecomment-3859642760

From rvansa at openjdk.org  Fri Feb  6 12:27:35 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Feb 2026 12:27:35 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
 <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
Message-ID: <LjJ2r2YMx9NgBTXg8h4zpOhkZ313JpHsCT6lNu4GQWo=.7ef480d1-db1a-4ac1-be3b-c58747e6aa60@github.com>

On Fri, 6 Feb 2026 08:21:27 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'crac' into simengine_separation
>>  - Fix tests on non-Linux
>>  - Try fix Windows build
>>  - Address review comments
>>  - Fixup
>>  - Fixups
>>  - Implement static build & other platforms
>>  - JDK-8376959: [CRaC] Turn simengine into shared library
>
> src/java.base/share/native/libcrcommon/crcommon.hpp line 83:
> 
>> 81: 
>> 82: extern "C" {
>> 83:   extern CRCOMMON_API const char* log_prefix;
> 
> Nitpick: this looks like it should be a part of `crlib_conf_t`. `LOG` can accept `conf` as parameter ? does not seem too bulky. If the conf will be an opaque type then ` const char* log_prefix(const crlib_conf*)` will also be needed.

Architecturally that would fit better, I went for a global variable since it's inconvenient to pass the conf to every static helper function that might error.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2773873443

From rvansa at openjdk.org  Fri Feb  6 12:31:07 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Feb 2026 12:31:07 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <yBE0epCURptS9oTwmCG1cYK0C-qm34YvJw2e9nKiluA=.000af4e3-1d0a-4c4c-b671-7d244a1a4ae2@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
 <p_sfZnd4uOA2WYkYWr6dGR1YS1k7nUQrquQ90-_iztA=.bf8d5a8c-20eb-4912-b3af-1346936c1a64@github.com>
 <yBE0epCURptS9oTwmCG1cYK0C-qm34YvJw2e9nKiluA=.000af4e3-1d0a-4c4c-b671-7d244a1a4ae2@github.com>
Message-ID: <ksATgLvG_hJC2TPYqab4OiDWZ7Ws0EQTOOQ7habSX9k=.890f447e-d9e2-4db6-b6b4-c7bfa8e80461@github.com>

On Tue, 3 Feb 2026 14:41:51 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> April 2026 is 27, a STS version, and 28 is STS as well (not that it would matter so much in CRaC - we haven't been updating the older branches anyway). I am OK to expire this in 28, though.
>
> I meant that in OpenJDK we will use 27 for deprecation and 28 for obsoletion, but in our downstream LTS releases we will need to pick versions with the corresponding major versions, otherwise they will never reach the deprecation/obsoletion/expiration. And for that I propose to use the versions that will be released in April 2026 and April 2027.

How would you want to record the obsoletion? Fetching JVM version constant from somewhere + static_assert?

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2773893126

From rvansa at openjdk.org  Fri Feb  6 13:38:58 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Feb 2026 13:38:58 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <LAJ3inBVPi2lt2ch5iwZBTMReED_y_DxWAWzAbd1HVg=.f4409115-830b-4e8c-a07b-2e3d1228714d@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
 <m-J_JCw8TMrIFy8wzgq2z6ov-DeooyyNkn6GM_pdjxg=.82bcd4a6-9550-4a51-80e9-2b4f1f8d85d3@github.com>
 <LAJ3inBVPi2lt2ch5iwZBTMReED_y_DxWAWzAbd1HVg=.f4409115-830b-4e8c-a07b-2e3d1228714d@github.com>
Message-ID: <YXGHRqwppjiuAS7kKUdPpTVfAqDDLvelaponXeOFGbM=.c4e842dd-d932-478e-bb2d-7b1bb799e319@github.com>

On Thu, 5 Feb 2026 13:56:38 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> > The point of this PR is not to change crexec, that's why I haven't really touched the README. I think that it can be completely removed in the follow-up
> 
> We added the doc because otherwise the format of saved scores is not documented anywhere. I am OK with addressing this in the PR that will remove crexec but the doc should be retained in some place common for engines that use crcommon.

I've checked the README again, and I think that for the reason's above it should be retained as-is in `libcrexec`/`libcriuengine`, rather than in libcrcommon. I can add a README into `libsimengine` saying that the format should be the same as `libcrexec`, but the existence of `libcrcommon` is an implementation detail, rather than something user-facing.

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3860514850

From snazarki at openjdk.org  Mon Feb  9 21:58:31 2026
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 9 Feb 2026 21:58:31 GMT
Subject: [crac] Integrated: 8362238: [CRaC]
 crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout
In-Reply-To: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
References: <5oEM-YYpIVBMkmUKpiqj5wQUktG8NpnTSpTBfBBbCkM=.41bea8f9-4acd-4012-b870-8f55294d210f@github.com>
Message-ID: <waVlQc8cUCaGuEjt-FeLdXX89GyCZw3yG92L6p2gMLs=.98f0e083-fb07-4016-b32f-e2c099576159@github.com>

On Thu, 5 Feb 2026 14:04:10 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> test/jdk/jdk/crac/fileDescriptors/FileWatcherThreadTest.java may be affected by race condition. Particularly case with checkpointWithoutKey=false may wait infinite temporary file is created before WatchKey is acquired. Since the bug is never reproduced locally I suggest to fix step-by-step. Let?s introduce timeout case firstly.

This pull request has now been integrated.

Changeset: adf639c8
Author:    Sergey Nazarkin <snazarki at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/adf639c8ee9b2e1f8c94aea266f817c5a79651ee
Stats:     9 lines in 1 file changed: 5 ins; 0 del; 4 mod

8362238: [CRaC] crac/fileDescriptors/FileWatcherThreadTest should wait for events with timeout

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Mon Feb  9 21:58:24 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 9 Feb 2026 21:58:24 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v5]
In-Reply-To: <YXGHRqwppjiuAS7kKUdPpTVfAqDDLvelaponXeOFGbM=.c4e842dd-d932-478e-bb2d-7b1bb799e319@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <Gdt1JlZcevYu1IgUOZUNE1wcf7lTtu1QuNb6C7IEl9A=.4f0955a9-2bc6-4c1a-a3c9-068806eb4e2b@github.com>
 <m-J_JCw8TMrIFy8wzgq2z6ov-DeooyyNkn6GM_pdjxg=.82bcd4a6-9550-4a51-80e9-2b4f1f8d85d3@github.com>
 <LAJ3inBVPi2lt2ch5iwZBTMReED_y_DxWAWzAbd1HVg=.f4409115-830b-4e8c-a07b-2e3d1228714d@github.com>
 <YXGHRqwppjiuAS7kKUdPpTVfAqDDLvelaponXeOFGbM=.c4e842dd-d932-478e-bb2d-7b1bb799e319@github.com>
Message-ID: <IPUWfqXDoIAbVPVhb5_vPhotC9oRFK3Uytr_PcoPjgQ=.c5c200ff-e71b-464a-8345-98ffbea2cd08@github.com>

On Fri, 6 Feb 2026 13:36:25 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> I can add a README into libsimengine saying that the format should be the same as libcrexec

Sounds good to me

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

PR Comment: https://git.openjdk.org/crac/pull/289#issuecomment-3869972351

From rvansa at openjdk.org  Mon Feb  9 21:58:46 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Feb 2026 21:58:46 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
 <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
Message-ID: <Zaa_8ovzuyfYH9GY-CkhZy9d_Qd_C-2hUiPWdzJ26Gc=.eae0567c-89d5-4bc5-8149-d2ec3328a7ce@github.com>

On Fri, 6 Feb 2026 08:12:09 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'crac' into simengine_separation
>>  - Fix tests on non-Linux
>>  - Try fix Windows build
>>  - Address review comments
>>  - Fixup
>>  - Fixups
>>  - Implement static build & other platforms
>>  - JDK-8376959: [CRaC] Turn simengine into shared library
>
> src/java.base/share/native/libcrcommon/crcommon.hpp line 74:
> 
>> 72:   void *image_constraints;
>> 73:   void *image_score;
>> 74: };
> 
> Since we want to use the C layer a more conventional way seems to be to move this definition to `crcommon.cpp` (it can even become a normal class with a constructor/destructor) and use composition instead of inheritance (engine classes would be `struct crlib_conf`s themselves, `bool init_conf(conf_t* conf, ...)` would become `conf_t* create_conf(...)`). These fields are not used directly anywhere except `crcommon.cpp` anyway.
> 
> Otherwise the fields can at least become their actual types to remove the casts in `crcommon.cpp`.

I want to keep the full extension definition in crcommon and with that I won't avoid either inheritance, or globally set function: in crcommon I need to be able to translate `crlib_conf_t` into `conf_t`. Which way would you prefer?

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2774582847

From tpushkin at openjdk.org  Mon Feb  9 21:58:53 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 9 Feb 2026 21:58:53 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <Zaa_8ovzuyfYH9GY-CkhZy9d_Qd_C-2hUiPWdzJ26Gc=.eae0567c-89d5-4bc5-8149-d2ec3328a7ce@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
 <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
 <Zaa_8ovzuyfYH9GY-CkhZy9d_Qd_C-2hUiPWdzJ26Gc=.eae0567c-89d5-4bc5-8149-d2ec3328a7ce@github.com>
Message-ID: <NS1QWewjPVqtw-a-IK4_hPRQCgvfLHjXI0EN7aTM5FM=.9f6e4d86-ca08-4a18-bc96-bc56a7ff821a@github.com>

On Fri, 6 Feb 2026 14:58:25 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/native/libcrcommon/crcommon.hpp line 74:
>> 
>>> 72:   void *image_constraints;
>>> 73:   void *image_score;
>>> 74: };
>> 
>> Since we want to use the C layer a more conventional way seems to be to move this definition to `crcommon.cpp` (it can even become a normal class with a constructor/destructor) and use composition instead of inheritance (engine classes would be `struct crlib_conf`s themselves, `bool init_conf(conf_t* conf, ...)` would become `conf_t* create_conf(...)`). These fields are not used directly anywhere except `crcommon.cpp` anyway.
>> 
>> Otherwise the fields can at least become their actual types to remove the casts in `crcommon.cpp`.
>
> I want to keep the full extension definition in crcommon and with that I won't avoid either inheritance, or globally set function: in crcommon I need to be able to translate `crlib_conf_t` into `conf_t`. Which way would you prefer?

Ah, I see, extension methods require `crlib_conf_t`. Ok, let's keep the inheritance.

Field types can be improved anyway though:

class ImageConstraints;
class ImageScore;

struct crlib_conf {
  ImageConstraints* image_constraints;
  ImageScore* image_score;
};

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2781241183

From rvansa at openjdk.org  Mon Feb  9 21:59:17 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Feb 2026 21:59:17 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v8]
In-Reply-To: <LjJ2r2YMx9NgBTXg8h4zpOhkZ313JpHsCT6lNu4GQWo=.7ef480d1-db1a-4ac1-be3b-c58747e6aa60@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <crVNBhk3rSkCmFVkgpCdjJBHO3Qub9PWk34tGP40qMA=.c24a0715-1754-4f90-aba6-4eba6d86dc3b@github.com>
 <Yh2CEf-C5mi7U5IYupnZwUrMznEuj9Yrh-3Vsac1YWM=.b0e40163-b475-47a7-88dc-908fb03d8cf3@github.com>
 <LjJ2r2YMx9NgBTXg8h4zpOhkZ313JpHsCT6lNu4GQWo=.7ef480d1-db1a-4ac1-be3b-c58747e6aa60@github.com>
Message-ID: <OyfOGRSIr6zaKNSuHNVPmuko22r4uZr0nQDG2PFDnco=.4531e484-d9e6-4a14-9e4d-a5cde927632b@github.com>

On Fri, 6 Feb 2026 12:24:23 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/native/libcrcommon/crcommon.hpp line 83:
>> 
>>> 81: 
>>> 82: extern "C" {
>>> 83:   extern CRCOMMON_API const char* log_prefix;
>> 
>> Nitpick: this looks like it should be a part of `crlib_conf_t`. `LOG` can accept `conf` as parameter ? does not seem too bulky. If the conf will be an opaque type then ` const char* log_prefix(const crlib_conf*)` will also be needed.
>
> Architecturally that would fit better, I went for a global variable since it's inconvenient to pass the conf to every static helper function that might error.

I've tried to refactor things but turns out this requires boilerplate, or weird conventions. Let's keep this and the `crlib_conf_t` -> `crcommon_conf_t` global.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2774902728

From tpushkin at openjdk.org  Tue Feb 10 09:50:12 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 10 Feb 2026 09:50:12 GMT
Subject: [crac] RFR: 8377546: [CRaC] Make
 CheckpointRestorePathTest.testRestoreNoImage platform-dependent
Message-ID: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>

Makes `CheckpointRestorePathTest.testRestoreNoImage` expect the actual error message on non-x86 platforms.

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

Commit messages:
 - Make testRestoreNoImage platform-dependent

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

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

From tpushkin at openjdk.org  Tue Feb 10 11:04:49 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 10 Feb 2026 11:04:49 GMT
Subject: [crac] RFR: 8377546: [CRaC] Make
 CheckpointRestorePathTest.testRestoreNoImage platform-dependent
In-Reply-To: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
References: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
Message-ID: <VYt6J35gdGVaE19j-CPVKAGBvw5p4oakqif9C52TZEA=.37a19420-c918-4993-8b59-37bbfb08b77a@github.com>

On Tue, 10 Feb 2026 09:41:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `CheckpointRestorePathTest.testRestoreNoImage` expect the actual error message on non-x86 platforms.

CI failed in unrelated test, looks like an issue with the test

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

PR Comment: https://git.openjdk.org/crac/pull/294#issuecomment-3876913122

From rvansa at openjdk.org  Tue Feb 10 12:29:42 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Feb 2026 12:29:42 GMT
Subject: [crac] RFR: 8377546: [CRaC] Make
 CheckpointRestorePathTest.testRestoreNoImage platform-dependent
In-Reply-To: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
References: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
Message-ID: <CdDXCwgPaaxzIp1YY5_n0hyMv_P2rEQ3ptiHLe25d_0=.6e7b8e4e-3026-4ce9-bd38-564a9dfe66e8@github.com>

On Tue, 10 Feb 2026 09:41:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `CheckpointRestorePathTest.testRestoreNoImage` expect the actual error message on non-x86 platforms.

OK, let's fix it for real in a follow-up.

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/294#pullrequestreview-3778641119

From tpushkin at openjdk.org  Tue Feb 10 12:35:30 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 10 Feb 2026 12:35:30 GMT
Subject: [crac] Integrated: 8377546: [CRaC] Make
 CheckpointRestorePathTest.testRestoreNoImage platform-dependent
In-Reply-To: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
References: <1iUudeMXGywKUP9wy92kpJbO__66REtBcwZPxdIJt9s=.32dd8ddc-a52e-4a7a-baca-51bad1a252af@github.com>
Message-ID: <jQEVIVavlT_NXAA5q-9iXUDdIOZQIdSjU1evwF3gWrM=.757e8c33-21b3-4352-b4c0-d7a30420bc44@github.com>

On Tue, 10 Feb 2026 09:41:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `CheckpointRestorePathTest.testRestoreNoImage` expect the actual error message on non-x86 platforms.

This pull request has now been integrated.

Changeset: 79c12195
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/79c1219527ec513b6c489109216ec851bc14def3
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8377546: [CRaC] Make CheckpointRestorePathTest.testRestoreNoImage platform-dependent

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Tue Feb 10 13:43:14 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 10 Feb 2026 13:43:14 GMT
Subject: [crac] RFR: 8377562: [CRaC] Add better logging to RemoteJmxTest
Message-ID: <px8AmJUsp3kLbC-DzxOC7oNWaIqQVR-GBCIwinCRQu0=.f3faffcf-e234-4b69-b629-e1e305a64947@github.com>

Makes `RemoteJmxTest` log stderr of the child process.

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

Commit messages:
 - Add better logging to RemoteJmxTest

Changes: https://git.openjdk.org/crac/pull/295/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=295&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377562
  Stats: 34 lines in 1 file changed: 16 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/crac/pull/295.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/295/head:pull/295

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

From rvansa at openjdk.org  Wed Feb 11 10:02:34 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 11 Feb 2026 10:02:34 GMT
Subject: [crac] RFR: 8377562: [CRaC] Add better logging to RemoteJmxTest
In-Reply-To: <px8AmJUsp3kLbC-DzxOC7oNWaIqQVR-GBCIwinCRQu0=.f3faffcf-e234-4b69-b629-e1e305a64947@github.com>
References: <px8AmJUsp3kLbC-DzxOC7oNWaIqQVR-GBCIwinCRQu0=.f3faffcf-e234-4b69-b629-e1e305a64947@github.com>
Message-ID: <sXzIa5eHpu6kMSt_4dPw1cMy7LURyf58vTK28HpMjsc=.d5d897f3-e77a-47b9-93d5-564e15e1a913@github.com>

On Tue, 10 Feb 2026 13:34:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `RemoteJmxTest` log stderr of the child process.

test/jdk/jdk/crac/RemoteJmxTest.java line 83:

> 81:                         System.out.println("[CHILD STDOUT] " + line);
> 82:                         if (!bootedFuture.isDone()) {
> 83:                             if (BOOTED.equals(line)) bootedFuture.complete(null);

This code looks like as if you expect that the messages could be printed multiple times; if that happens this should fail the test (for simplicity I wouldn't mind if it fails by timeout in the end, though, as long as the reason is printed earlier in the log).

I wonder if this could be consolidated with `CracProcess.waitForStdout()` (the least the lines are prefixed here. Maybe the best interface would be

CountDownLatch<Void> watch(String line, boolean positiveMatch);

(called repeatedly to get multiple latches), and `waitForStdout` would use that.

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

PR Review Comment: https://git.openjdk.org/crac/pull/295#discussion_r2789451757

From rvansa at openjdk.org  Wed Feb 11 10:03:03 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 11 Feb 2026 10:03:03 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v9]
In-Reply-To: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
Message-ID: <15WTQRnsdq3m_Q-BzMm0QXR-aY8vCfYtxo6OF8O_5r0=.56c276bc-02c8-46e5-8279-89fe4ad3d9e8@github.com>

> Right now `simengine` is implemented as an executable, invoked through `libcrexec` that implements the C/R API. Since the programmatic C/R API should be the main interface, any exec API is redundant; let's turn `simengine` into shared (dynamic) library implementing the API on its own.
> 
> The `pauseengine` does not need to exist on its own; this can be only an option `pause=true` for `simengine`. The implementation is Linux only (and it is out of scope to fill in a non-Linux implementation - the `pause` option can be just excluded in non-Linux `libsimengine`).
> 
> We expect to turn `libcrexec` + `criuengine` into `libcriuengine` in a follow up (not as part of this issue).

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

 - Improve deprecation notice
 - ifdef LINUX
 - Add simengine README
 - Make crcommon opaque, remove static_casts, check version

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

Changes:
  - all: https://git.openjdk.org/crac/pull/289/files
  - new: https://git.openjdk.org/crac/pull/289/files/a3c3154e..df1a04c0

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

  Stats: 171 lines in 6 files changed: 49 ins; 28 del; 94 mod
  Patch: https://git.openjdk.org/crac/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/289/head:pull/289

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

From tpushkin at openjdk.org  Wed Feb 11 10:03:11 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 11 Feb 2026 10:03:11 GMT
Subject: [crac] RFR: 8376959: [CRaC] Turn simengine into shared library
 [v2]
In-Reply-To: <ksATgLvG_hJC2TPYqab4OiDWZ7Ws0EQTOOQ7habSX9k=.890f447e-d9e2-4db6-b6b4-c7bfa8e80461@github.com>
References: <SvnzjtBLtvPlGp52ESKjZRTWn6LMWl1aqgUg8Gyfgmw=.6135242d-65c8-4cc2-8342-11d439c459c4@github.com>
 <v_dR0Ps4DLfzu9uPU5P5yhH89AF8nVXVMqoxIkRDRKM=.07fb051d-4ff7-4632-b170-1f36fbc4d301@github.com>
 <sM_uotFYrjcVSEoOomb9nqt7Ujy92KCyJbOqnluUGJ4=.ce03d505-d27d-470f-a77e-ab7c08dbe19e@github.com>
 <p_sfZnd4uOA2WYkYWr6dGR1YS1k7nUQrquQ90-_iztA=.bf8d5a8c-20eb-4912-b3af-1346936c1a64@github.com>
 <yBE0epCURptS9oTwmCG1cYK0C-qm34YvJw2e9nKiluA=.000af4e3-1d0a-4c4c-b671-7d244a1a4ae2@github.com>
 <ksATgLvG_hJC2TPYqab4OiDWZ7Ws0EQTOOQ7habSX9k=.890f447e-d9e2-4db6-b6b4-c7bfa8e80461@github.com>
Message-ID: <j8i-coAHvFWN7tG4a1DXVmo9778PImOyZnbnC5UKKjE=.2bd4c77e-4eeb-440d-9848-63965e5eed17@github.com>

On Fri, 6 Feb 2026 12:28:06 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> I meant that in OpenJDK we will use 27 for deprecation and 28 for obsoletion, but in our downstream LTS releases we will need to pick versions with the corresponding major versions, otherwise they will never reach the deprecation/obsoletion/expiration. And for that I propose to use the versions that will be released in April 2026 and April 2027.
>
> How would you want to record the obsoletion? Fetching JVM version constant from somewhere + static_assert?

I posted the code above. Yes, via an assert, not sure if it can be static though.

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

PR Review Comment: https://git.openjdk.org/crac/pull/289#discussion_r2791637034