From jkratochvil at openjdk.org  Sun Jan  4 22:19:39 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 4 Jan 2026 22:19:39 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v2]
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: <IlbSFJu11A2jf2-cluwoo1AQFdqkui9kXr7FIdDwxtY=.7abbeb96-f090-499b-aa6d-efbe0889f077@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 five additional commits since the last revision:

 - return original prototype of is_failed(), add new get_failed_bitmap()
 - !EQUALS->SUBSET
 - conjunction->intersection
 - Merge branch 'crac' into crac-conjunction
 - 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo,0xbar on checkpoint

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/6bc03d25..1e0118fe

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

  Stats: 892 lines in 23 files changed: 397 ins; 448 del; 47 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  Sun Jan  4 22:19:41 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 4 Jan 2026 22:19:41 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v2]
In-Reply-To: <ze1L2MzSefHKmmWsSAusptTjHf7oC24aR33mwWFHoqU=.18cf961e-3ce5-4305-bbe3-d4b2c09093b5@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <ze1L2MzSefHKmmWsSAusptTjHf7oC24aR33mwWFHoqU=.18cf961e-3ce5-4305-bbe3-d4b2c09093b5@github.com>
Message-ID: <fhnyRsGt-m-XD3isCg3XTCrLutTI_ym7gF5NBMTcIdU=.e339fd13-de80-4665-b31c-f131c5f080f3@github.com>

On Tue, 2 Dec 2025 13:44:33 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> A test update along with a bugfix would be welcome.

I see in https://github.com/openjdk/crac/commit/3260337b25ecb9198ad75af3ccc59272c0ffaa86 only `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` which has been removed by https://github.com/openjdk/crac/pull/280 . There there is a downstream testcase ZULU-82680 which already assumes this change.

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

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

From jkratochvil at openjdk.org  Sun Jan  4 22:19:42 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 4 Jan 2026 22:19:42 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v2]
In-Reply-To: <3quObRLXmnFukUm6tXRNGEwbA8sm1iWZ2GHPhvu9zBk=.f9368fc3-8eb1-4c74-9a5d-c678bf7ab2f0@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <ze1L2MzSefHKmmWsSAusptTjHf7oC24aR33mwWFHoqU=.18cf961e-3ce5-4305-bbe3-d4b2c09093b5@github.com>
 <NK8w4QeBn-Y64i-26_tVT_NaXB35-JiuQ9s8LaCBywI=.e4b04845-8426-4145-b069-7890d75fd936@github.com>
 <3quObRLXmnFukUm6tXRNGEwbA8sm1iWZ2GHPhvu9zBk=.f9368fc3-8eb1-4c74-9a5d-c678bf7ab2f0@github.com>
Message-ID: <yLR4cMuJ0qBfpaTkVqy2fwrx-G3EeviMLKVcA4OSZoE=.9b5b2990-c44c-4abb-87dd-6fffa724379c@github.com>

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

>> Have there been any JDK releases since we introduced this API? I think not, then we should still be free to change it, shouldn't we?
>> 
>> I haven't looked into the bug, so cannot comment on the change itself, just noticed this message.
>
> Maybe there should be `is_failed_label` and `is_failed_bitmap` but I just wanted something to get it running.

Addressed this by: https://github.com/openjdk/crac/pull/278/commits/1e0118fe6556838911801e5895ff29644977dfbc

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

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

From tpushkin at openjdk.org  Mon Jan  5 10:04:42 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 5 Jan 2026 10:04:42 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v2]
In-Reply-To: <UcDv7qqhsjYJ3_SkN7IlbabR_Qyzl56nTSjrHco5vJc=.5e2b4d4f-623e-4f80-a7fb-f95e0a31ff56@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <UcDv7qqhsjYJ3_SkN7IlbabR_Qyzl56nTSjrHco5vJc=.5e2b4d4f-623e-4f80-a7fb-f95e0a31ff56@github.com>
Message-ID: <2xjmqO3jJtkb-06ybAJTYK1pIHd5rQjDLWfvComx1-E=.7b6f337b-fda7-4e7b-8ab3-7d8f1334a707@github.com>

On Mon, 1 Dec 2025 08:30:59 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
>> 
>> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set FD value on Windows, too

I haven't read through `SelectorCRaCSupport` very carefully since it's mainly pre-existing code

src/java.base/share/classes/jdk/internal/crac/ClaimedFDs.java line 89:

> 87:                         assert fileDescriptorAccess.getHandle(entry.getKey()) != -1;
> 88:                         // On Windows the native FDs check is a no-op, but we need to set
> 89:                         // the FD to prevent assertion failure on Descriptor.getFd()

Maybe allow -1 as a value? Having 0 may be confusing as it is a valid FD value.

In the future, it looks like we need a more general abstraction for FD/handle.

src/java.base/share/classes/sun/nio/ch/SelectorCRaCSupport.java line 1:

> 1: package sun.nio.ch;

Missing license header

src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java line 125:

> 123:     @Override
> 124:     protected Collection<FileDescriptor> claimFileDescriptors() {
> 125:         // What about WEPoll eph?

Looks like this become a TODO/FIXME

test/jdk/jdk/crac/fileDescriptors/ReopenListeningWithSelectorTest.java line 48:

> 46:  * @library /test/lib
> 47:  * @modules java.base/jdk.internal.crac:+open
> 48:  * @requires (os.family == "linux")

I haven't tested this but `PollSelectorProvider` is in `unix` directory so it should be available on other POSIX platforms. So maybe `os.family != "windows"`?

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

PR Review: https://git.openjdk.org/crac/pull/276#pullrequestreview-3625915226
PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2660931604
PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2660811552
PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2660888444
PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2660684061

From rvansa at openjdk.org  Mon Jan  5 15:28:06 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 5 Jan 2026 15:28:06 GMT
Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other
 platforms [v5]
In-Reply-To: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
References: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
Message-ID: <llIiNL0jWHY8hDorXR4IHQ60FJ54X8nfi2VSu7hTPHo=.5043d88a-1526-4fa0-aa31-a194193b2525@github.com>

> Currently `-XX:CPUFeatures` option is available only on `x86_64`. This complicates creating multiarch container images that are meant to be universally runnable (with `-XX:CPUFeatures=generic`).
> 
> I propose to make this option available on all architectures, with the non-arch specific values:
> * `generic`
> * `native`
> * `ignore`
> 
> The implementation on non-x86_64 will only validate the sanity of the value.
> 
> The related option `-XX:+ShowCPUFeatures` will print an informative message (saying that the option does not make much sense).
> 
> `-XX:+IgnoreCPUFeatures` will be permitted as well, but it will be a no-op on the other architectures.

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

  Fail on x86 non-Linux with not recognized CPUFeatures pattern

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

Changes:
  - all: https://git.openjdk.org/crac/pull/282/files
  - new: https://git.openjdk.org/crac/pull/282/files/e4849639..0bab0747

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

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

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

From jkratochvil at openjdk.org  Mon Jan  5 19:56:12 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 5 Jan 2026 19:56:12 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load
Message-ID: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>

A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).

On AWS m1.small:

bin/java -XX:+ShowCPUFeatures --version
This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
openjdk 25-internal 2025-09-16
OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)

That is a needless re-exec.

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

Commit messages:
 - ZULU-84726: CPUFeatures: check performance regression of AVX_Fast_Unaligned_Load

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

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

From tpushkin at openjdk.org  Mon Jan  5 19:56:15 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 5 Jan 2026 19:56:15 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load
In-Reply-To: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
Message-ID: <Ex08n8LrO6G2FflVX1YeyntivH3TQp56RFEEAB1Yemw=.a5e6ec61-a034-4337-a828-fcb1c5106fe5@github.com>

On Sun, 4 Jan 2026 23:58:39 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
> 
> On AWS m1.small:
> 
> bin/java -XX:+ShowCPUFeatures --version
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
> 
> That is a needless re-exec.

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

> 1199: #define EXCESSIVE(tunables) EXCESSIVE2(tunables, FEATURE_ACTIVE(tunables))
> 1200: // There is no CPU_FEATURE_ACTIVE() available for this symbol.
> 1201: #define EXCESSIVE_GLIBC_PREFERRED(tunables) EXCESSIVE2(tunables, !from_reexec)

`from_reexec` can now become a non-static variable inside `glibc_env_set`.

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

> 1230:   // There is no CPU_FEATURE_ACTIVE() available for this symbol.
> 1231:   // There is no check for 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' but FEATURE_ACTIVE(AVX) depends on it so it can be assumed.
> 1232:   EXCESSIVE2(AVX_Fast_Unaligned_Load, FEATURE_ACTIVE(OSXSAVE) && FEATURE_ACTIVE(AVX) && FEATURE_ACTIVE(AVX2));

Since we check it like this here, I'd again suggest simplifying the detection of `AVX_Fast_Unaligned_Load` in `feature_flags()` to `vm_features.supports_feature(CPU_OSXSAVE) && vm_features.supports_feature(CPU_AVX) && vm_features.supports_feature(CPU_AVX2)` (maybe with `assert(xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0)`), but I don't insist.

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

PR Review Comment: https://git.openjdk.org/crac/pull/283#discussion_r2660503450
PR Review Comment: https://git.openjdk.org/crac/pull/283#discussion_r2660516760

From jkratochvil at openjdk.org  Mon Jan  5 20:02:49 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 5 Jan 2026 20:02:49 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v2]
In-Reply-To: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
Message-ID: <A2c6hLjtYy5TFX3gVhpcXW9yDVrjGLF7vEzqFr0_9Es=.3395b189-032a-4453-a621-47f32d540039@github.com>

> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
> 
> On AWS m1.small:
> 
> bin/java -XX:+ShowCPUFeatures --version
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
> 
> That is a needless re-exec.

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

  Make from_reexec a local variable

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

Changes:
  - all: https://git.openjdk.org/crac/pull/283/files
  - new: https://git.openjdk.org/crac/pull/283/files/1abc8a9e..335faadf

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

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

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

From jkratochvil at openjdk.org  Mon Jan  5 21:51:58 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 5 Jan 2026 21:51:58 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v3]
In-Reply-To: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
Message-ID: <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>

> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
> 
> On AWS m1.small:
> 
> bin/java -XX:+ShowCPUFeatures --version
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
> 
> That is a needless re-exec.

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

  Adjust the 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' detection

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

Changes:
  - all: https://git.openjdk.org/crac/pull/283/files
  - new: https://git.openjdk.org/crac/pull/283/files/335faadf..0274da4a

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

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

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

From jkratochvil at openjdk.org  Mon Jan  5 21:52:00 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 5 Jan 2026 21:52:00 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v3]
In-Reply-To: <Ex08n8LrO6G2FflVX1YeyntivH3TQp56RFEEAB1Yemw=.a5e6ec61-a034-4337-a828-fcb1c5106fe5@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
 <Ex08n8LrO6G2FflVX1YeyntivH3TQp56RFEEAB1Yemw=.a5e6ec61-a034-4337-a828-fcb1c5106fe5@github.com>
Message-ID: <6iPjV3YyZas3WgDryK8QZviDtA1mpu_7qqG6A122idk=.12e0256c-63fb-4cce-a837-61d5f0300b93@github.com>

On Mon, 5 Jan 2026 07:21:01 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust the 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' detection
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1232:
> 
>> 1230:   // There is no CPU_FEATURE_ACTIVE() available for this symbol.
>> 1231:   // There is no check for 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' but FEATURE_ACTIVE(AVX) depends on it so it can be assumed.
>> 1232:   EXCESSIVE2(AVX_Fast_Unaligned_Load, FEATURE_ACTIVE(OSXSAVE) && FEATURE_ACTIVE(AVX) && FEATURE_ACTIVE(AVX2));
> 
> Since we check it like this here, I'd again suggest simplifying the detection of `AVX_Fast_Unaligned_Load` in `feature_flags()` to `vm_features.supports_feature(CPU_OSXSAVE) && vm_features.supports_feature(CPU_AVX) && vm_features.supports_feature(CPU_AVX2)` (maybe with `assert(xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0)`), but I don't insist.

I have adjusted it somehow.

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

PR Review Comment: https://git.openjdk.org/crac/pull/283#discussion_r2662899045

From tpushkin at openjdk.org  Tue Jan  6 06:42:46 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 6 Jan 2026 06:42:46 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v3]
In-Reply-To: <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
 <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
Message-ID: <Xxx4LscE8GoWr7CzyiKOab09J80nZf-LlYHaZQe31Xc=.e893471b-337d-4164-9ad4-0292ab65a0fb@github.com>

On Mon, 5 Jan 2026 21:51:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
>> 
>> On AWS m1.small:
>> 
>> bin/java -XX:+ShowCPUFeatures --version
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> openjdk 25-internal 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
>> 
>> That is a needless re-exec.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' detection

LGTM.

The test failure seems unrelated, please open a bug for it

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

Marked as reviewed by tpushkin (Committer).

PR Review: https://git.openjdk.org/crac/pull/283#pullrequestreview-3629635998

From rvansa at openjdk.org  Tue Jan  6 10:09:01 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 6 Jan 2026 10:09:01 GMT
Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other
 platforms [v5]
In-Reply-To: <_n1jc-oGio4Z5Aoh5-vkSf62L9KPS0ZAPeWdyhSKzQc=.40ce23ee-0b17-4546-81c7-9ebff738ef9f@github.com>
References: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
 <_n1jc-oGio4Z5Aoh5-vkSf62L9KPS0ZAPeWdyhSKzQc=.40ce23ee-0b17-4546-81c7-9ebff738ef9f@github.com>
Message-ID: <hhPZIxV3xbaJx0aJrqTEIoVkjAN3KxnjTF5oVeN58Ow=.7a28ed4a-3cac-4ff9-8697-5384d2a264e4@github.com>

On Mon, 22 Dec 2025 14:54: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:
>> 
>>   Fail on x86 non-Linux with not recognized CPUFeatures pattern
>
> Implementation LGTM, but we have non-x86 machines in CI so it makes sense to add a test for this

@TimPushkin The tests now pass on all platforms but Mac + x64, where we need to backport upstream changes after GH obsoleted a base image. Please re-review.

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

PR Comment: https://git.openjdk.org/crac/pull/282#issuecomment-3714044685

From tpushkin at openjdk.org  Tue Jan  6 13:36:34 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 6 Jan 2026 13:36:34 GMT
Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other
 platforms [v5]
In-Reply-To: <llIiNL0jWHY8hDorXR4IHQ60FJ54X8nfi2VSu7hTPHo=.5043d88a-1526-4fa0-aa31-a194193b2525@github.com>
References: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
 <llIiNL0jWHY8hDorXR4IHQ60FJ54X8nfi2VSu7hTPHo=.5043d88a-1526-4fa0-aa31-a194193b2525@github.com>
Message-ID: <lBdLNceKqNKbyWzwphfqT9XNbgkagRyfAlTeUmtFr0E=.ea5b1a2f-02c9-4ea9-8afd-03ee5608cd06@github.com>

On Mon, 5 Jan 2026 15:28:06 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Currently `-XX:CPUFeatures` option is available only on `x86_64`. This complicates creating multiarch container images that are meant to be universally runnable (with `-XX:CPUFeatures=generic`).
>> 
>> I propose to make this option available on all architectures, with the non-arch specific values:
>> * `generic`
>> * `native`
>> * `ignore`
>> 
>> The implementation on non-x86_64 will only validate the sanity of the value.
>> 
>> The related option `-XX:+ShowCPUFeatures` will print an informative message (saying that the option does not make much sense).
>> 
>> `-XX:+IgnoreCPUFeatures` will be permitted as well, but it will be a no-op on the other architectures.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fail on x86 non-Linux with not recognized CPUFeatures pattern

Just two minor things, since you are planning a follow-up maybe it'll be easier/faster to fix them there

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

> 954:   vm_exit_during_initialization(err_msg("VM option 'CPUFeatures=%s' must be of the form: %s", str_orig, buf + 1));
> 955:   return {};
> 956: #endif

I'd prefer to have either `#endif // LINUX` or `#endif // !LINUX` ? there is a lot of ifdef-s around so it's a bit harder to read without such comments

test/jdk/jdk/crac/CPUFeatures/SimpleCPUFeaturesTest.java line 2:

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

Suggestion:

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

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

Marked as reviewed by tpushkin (Committer).

PR Review: https://git.openjdk.org/crac/pull/282#pullrequestreview-3630898922
PR Review Comment: https://git.openjdk.org/crac/pull/282#discussion_r2664927506
PR Review Comment: https://git.openjdk.org/crac/pull/282#discussion_r2664932337

From rvansa at openjdk.org  Tue Jan  6 14:20:44 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 6 Jan 2026 14:20:44 GMT
Subject: [crac] Integrated: 8373781: [CRaC] Permit -XX:CPUFeatures on other
 platforms
In-Reply-To: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
References: <H1XOISgeh3m78tUeuS-NG_sAjzVn-zMAsaJmNAyawUk=.251ea303-a15b-4b5f-9d24-fb2d3fd3b7e9@github.com>
Message-ID: <wV9DxsulhVDk5yt6WnsvtO_aBLeelw2qxEBeVdUH9mM=.f13d5739-a00a-48df-b032-ca306dacf32d@github.com>

On Wed, 17 Dec 2025 10:26:55 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Currently `-XX:CPUFeatures` option is available only on `x86_64`. This complicates creating multiarch container images that are meant to be universally runnable (with `-XX:CPUFeatures=generic`).
> 
> I propose to make this option available on all architectures, with the non-arch specific values:
> * `generic`
> * `native`
> * `ignore`
> 
> The implementation on non-x86_64 will only validate the sanity of the value.
> 
> The related option `-XX:+ShowCPUFeatures` will print an informative message (saying that the option does not make much sense).
> 
> `-XX:+IgnoreCPUFeatures` will be permitted as well, but it will be a no-op on the other architectures.

This pull request has now been integrated.

Changeset: abf08680
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/abf086802d18239cdcf0091b8baaf2b25b510537
Stats:     274 lines in 22 files changed: 193 ins; 64 del; 17 mod

8373781: [CRaC] Permit -XX:CPUFeatures on other platforms

Reviewed-by: tpushkin

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

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

From rvansa at openjdk.org  Tue Jan  6 14:27:56 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 6 Jan 2026 14:27:56 GMT
Subject: [crac] RFR: 8374614: [CRaC] Remove defunct marking
Message-ID: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>

When initializing fdinfos, there might be a racy native thread closing FD between enumerating FDs and `readlink /proc/self/fd/XXX`, causing an error and assertion to fail.

Further looking into the code it seems that the fdinfo::mark is not read since https://github.com/openjdk/crac/commit/4b0dc2dc9722945579c9772b335a44fa79f1729f and therefore the whole check is defunct, and can be removed.

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

Commit messages:
 - 8374614: [CRaC] Remove defunct marking

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

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

From rvansa at openjdk.org  Tue Jan  6 14:47:20 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 6 Jan 2026 14:47:20 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
Message-ID: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>

Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.

In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
* compatible - this is the current behaviour (default)
* exact - require CPU features from the image to match perfectly
* skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.

The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

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

Commit messages:
 - 8373784: [CRaC] VM Option to require perfect CPU fit

Changes: https://git.openjdk.org/crac/pull/285/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373784
  Stats: 146 lines in 7 files changed: 137 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/crac/pull/285.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/285/head:pull/285

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

From jkratochvil at openjdk.org  Tue Jan  6 20:33:47 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 6 Jan 2026 20:33:47 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
In-Reply-To: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
Message-ID: <kQW-8TDW1m43RZWpzKHDhfE8q9zJyZMZNUzD5Yna-lQ=.8d3dd78b-3516-4efe-bd8d-5156d48a2c38@github.com>

On Tue, 6 Jan 2026 14:41:20 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
> 
> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
> * compatible - this is the current behaviour (default)
> * exact - require CPU features from the image to match perfectly
> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
> 
> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

src/hotspot/share/runtime/arguments.cpp line 584:

> 582:   { "CRaCAllowToSkipCheckpoint",    JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
> 583:   { "CRaCDoThrowCheckpointException", JDK_Version::undefined(), JDK_Version::jdk(25), JDK_Version::jdk(26) },
> 584:   { "IgnoreCPUFeatures",            JDK_Version::jdk(26), JDK_Version::jdk(29), JDK_Version::undefined() },

When it is deprecated one should update the existing message:

                "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures .",

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

PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2666203488

From jkratochvil at openjdk.org  Tue Jan  6 20:38:22 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 6 Jan 2026 20:38:22 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
In-Reply-To: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
Message-ID: <RMaT1tw6zmx5-2ozDm9TahXJKSa9G_zhAWnFPbizVy4=.cd27b0a5-9c40-4975-b6bd-88c36315078f@github.com>

On Tue, 6 Jan 2026 14:41:20 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
> 
> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
> * compatible - this is the current behaviour (default)
> * exact - require CPU features from the image to match perfectly
> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
> 
> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

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

> 822:       return;
> 823:     }
> 824:     ignore = true;

This has only local effect, `VM_Version::ignore_cpu_features()` would still return `false`. But that is a part of the `-XX:CPUFeatures=ignore` vs. `-XX:+IgnoreCPUFeatures` unification so it may be OK here.

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

PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2666215996

From rvansa at openjdk.org  Wed Jan  7 15:35:32 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 7 Jan 2026 15:35:32 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
In-Reply-To: <RMaT1tw6zmx5-2ozDm9TahXJKSa9G_zhAWnFPbizVy4=.cd27b0a5-9c40-4975-b6bd-88c36315078f@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <RMaT1tw6zmx5-2ozDm9TahXJKSa9G_zhAWnFPbizVy4=.cd27b0a5-9c40-4975-b6bd-88c36315078f@github.com>
Message-ID: <LDTy5aKmL86JOpSYZfsJdEjJRKZUmSGtS7ggt5nGInM=.b474e266-614c-4418-8d38-2e4427697aa7@github.com>

On Tue, 6 Jan 2026 20:35:02 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> src/hotspot/share/runtime/crac.cpp line 824:
> 
>> 822:       return;
>> 823:     }
>> 824:     ignore = true;
> 
> This has only local effect, `VM_Version::ignore_cpu_features()` would still return `false`. But that is a part of the `-XX:CPUFeatures=ignore` vs. `-XX:+IgnoreCPUFeatures` unification so it may be OK here.

Not sure what you're suggesting. If `-XX:CPUFeatures=ignore` is set on checkpoint the function will always return `true`, because the features are not stored anyway, so the `CheckCPUFeatures` is practically ignored. Are you saying that we should emit some warning in here?

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

PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2668931948

From rvansa at openjdk.org  Wed Jan  7 15:37:43 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 7 Jan 2026 15:37:43 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
Message-ID: <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>

> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
> 
> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
> * compatible - this is the current behaviour (default)
> * exact - require CPU features from the image to match perfectly
> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
> 
> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

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

  Minor fixups

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

Changes:
  - all: https://git.openjdk.org/crac/pull/285/files
  - new: https://git.openjdk.org/crac/pull/285/files/c9ed0a90..75db21c9

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

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

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

From rvansa at openjdk.org  Wed Jan  7 16:26:26 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 7 Jan 2026 16:26:26 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v2]
In-Reply-To: <IlbSFJu11A2jf2-cluwoo1AQFdqkui9kXr7FIdDwxtY=.7abbeb96-f090-499b-aa6d-efbe0889f077@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <IlbSFJu11A2jf2-cluwoo1AQFdqkui9kXr7FIdDwxtY=.7abbeb96-f090-499b-aa6d-efbe0889f077@github.com>
Message-ID: <CZO0qi6OhbTD9FFE8eG6CAv6qnqM9WdJ-r3Z3tGdQ7Y=.060ac24b-538a-4ef6-b7de-5508df50ade0@github.com>

On Sun, 4 Jan 2026 22:19:39 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 five additional commits since the last revision:
> 
>  - return original prototype of is_failed(), add new get_failed_bitmap()
>  - !EQUALS->SUBSET
>  - conjunction->intersection
>  - Merge branch 'crac' into crac-conjunction
>  - 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo,0xbar on checkpoint

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

> 65:   bool (*is_failed)(crlib_conf_t *, const char *name);
> 66: 
> 67:   // For failed require_bitmap it will copy the expected value to the provided buffer.

I would expect this function to return the stored bitmap value (and you'd calculate the intersection only in the caller). If you want to use the current semantics please elaborate in the docs what is the 'expected value' for each of the `crlib_bitmap_comparison_t`.

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

> 81:     const void* data;
> 82:     size_t data_size;
> 83:     const void* intersection; // data_size

I think you can make this just (non-const) `unsigned char *` rather than all the nasty casts when computing the intersection.

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

> 92:       data = o.data;
> 93:       data_size = o.data_size;
> 94:       intersection = o.intersection;

missing `o.intersection = nullptr`

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

> 145:       if (!strcmp(c.name, name) && c.failed) {
> 146:         result = true;
> 147:         if (value_return && c.intersection && value_size == c.data_size) {

If `value_size != c.data_size` this will return `true`. I guess that if this won't report the required size it should just return false.

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

PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2669119837
PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2669098826
PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2669074064
PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2669087388

From rvansa at openjdk.org  Wed Jan  7 18:42:49 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 7 Jan 2026 18:42:49 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v3]
In-Reply-To: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
Message-ID: <nanresd44TNUBvM2YzVM4WNdfJyR9WbwW1obsX5bb4E=.d65fcac0-a5e0-42cb-a6b3-0fb95af7666d@github.com>

> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
> 
> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.

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

  Minor fixes

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

Changes:
  - all: https://git.openjdk.org/crac/pull/276/files
  - new: https://git.openjdk.org/crac/pull/276/files/8fff09d5..e90eac79

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

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

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

From rvansa at openjdk.org  Wed Jan  7 18:42:52 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 7 Jan 2026 18:42:52 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v2]
In-Reply-To: <2xjmqO3jJtkb-06ybAJTYK1pIHd5rQjDLWfvComx1-E=.7b6f337b-fda7-4e7b-8ab3-7d8f1334a707@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <UcDv7qqhsjYJ3_SkN7IlbabR_Qyzl56nTSjrHco5vJc=.5e2b4d4f-623e-4f80-a7fb-f95e0a31ff56@github.com>
 <2xjmqO3jJtkb-06ybAJTYK1pIHd5rQjDLWfvComx1-E=.7b6f337b-fda7-4e7b-8ab3-7d8f1334a707@github.com>
Message-ID: <-wv8UAhXfptGNxeJoaIqOU9-li0PMmhCCkBpwMjCLGY=.13a76676-0574-42ba-adeb-23467bae5b4d@github.com>

On Mon, 5 Jan 2026 09:59:08 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set FD value on Windows, too
>
> src/java.base/share/classes/jdk/internal/crac/ClaimedFDs.java line 89:
> 
>> 87:                         assert fileDescriptorAccess.getHandle(entry.getKey()) != -1;
>> 88:                         // On Windows the native FDs check is a no-op, but we need to set
>> 89:                         // the FD to prevent assertion failure on Descriptor.getFd()
> 
> Maybe allow -1 as a value? Having 0 may be confusing as it is a valid FD value.
> 
> In the future, it looks like we need a more general abstraction for FD/handle.

It is strange to allow -1 in a 'valid' Descriptor. And on Linux, which is our 'main' platform this does not happen - I think it is better to keep it this way. I could do `fd = Integer.MAX_VALUE` to differentiate this from stdin = 0.

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

PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2669658363

From jkratochvil at openjdk.org  Wed Jan  7 20:15:47 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 7 Jan 2026 20:15:47 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <LDTy5aKmL86JOpSYZfsJdEjJRKZUmSGtS7ggt5nGInM=.b474e266-614c-4418-8d38-2e4427697aa7@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <RMaT1tw6zmx5-2ozDm9TahXJKSa9G_zhAWnFPbizVy4=.cd27b0a5-9c40-4975-b6bd-88c36315078f@github.com>
 <LDTy5aKmL86JOpSYZfsJdEjJRKZUmSGtS7ggt5nGInM=.b474e266-614c-4418-8d38-2e4427697aa7@github.com>
Message-ID: <gv9b7lUTGc-wrVpx7pAhIBeYsNWv24-YfCfm_EiAqzE=.076638ee-e076-4984-8476-d4a70fe5b6cf@github.com>

On Wed, 7 Jan 2026 15:31:42 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac.cpp line 824:
>> 
>>> 822:       return;
>>> 823:     }
>>> 824:     ignore = true;
>> 
>> This has only local effect, `VM_Version::ignore_cpu_features()` would still return `false`. But that is a part of the `-XX:CPUFeatures=ignore` vs. `-XX:+IgnoreCPUFeatures` unification so it may be OK here.
>
> Not sure what you're suggesting. If `-XX:CPUFeatures=ignore` is set on checkpoint the function will always return `true`, because the features are not stored anyway, so the `CheckCPUFeatures` is practically ignored. Are you saying that we should emit some warning in here?

I was just bringing up ZULU-75248 is unfixed so I cannot say what `-XX:CheckCPUFeatures=skip` really should do. OK to resolve this thread.

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

PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2669936976

From jkratochvil at openjdk.org  Wed Jan  7 20:42:08 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 7 Jan 2026 20:42:08 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v3]
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: <na03q83XRXFUpvEUjKxTzrtseMxloOsV1GRNIbY5qiA=.4cc7c670-1746-4374-9ffa-8450bf44c2e7@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:

  Fixes upon review by Radim Vansa

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/1e0118fe..80b71be0

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

  Stats: 12 lines in 2 files changed: 5 ins; 0 del; 7 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  Wed Jan  7 20:42:11 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 7 Jan 2026 20:42:11 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v2]
In-Reply-To: <CZO0qi6OhbTD9FFE8eG6CAv6qnqM9WdJ-r3Z3tGdQ7Y=.060ac24b-538a-4ef6-b7de-5508df50ade0@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
 <IlbSFJu11A2jf2-cluwoo1AQFdqkui9kXr7FIdDwxtY=.7abbeb96-f090-499b-aa6d-efbe0889f077@github.com>
 <CZO0qi6OhbTD9FFE8eG6CAv6qnqM9WdJ-r3Z3tGdQ7Y=.060ac24b-538a-4ef6-b7de-5508df50ade0@github.com>
Message-ID: <Kn4cixm5_cYX11u6-6RpPPRrQ7B_NmZfR5l4An09Hgk=.35619d2b-fea2-4e91-bf78-9dce4b4e5e86@github.com>

On Wed, 7 Jan 2026 16:15:55 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> 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 five additional commits since the last revision:
>> 
>>  - return original prototype of is_failed(), add new get_failed_bitmap()
>>  - !EQUALS->SUBSET
>>  - conjunction->intersection
>>  - Merge branch 'crac' into crac-conjunction
>>  - 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo,0xbar on checkpoint
>
> src/java.base/share/native/libcrexec/image_constraints.hpp line 83:
> 
>> 81:     const void* data;
>> 82:     size_t data_size;
>> 83:     const void* intersection; // data_size
> 
> I think you can make this just (non-const) `unsigned char *` rather than all the nasty casts when computing the intersection.

I just copycatted the field `data` using similar casts.

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

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

From rvansa at openjdk.org  Thu Jan  8 07:04:20 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 8 Jan 2026 07:04:20 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v4]
In-Reply-To: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
Message-ID: <t3gDhygT32LMJn2SHJRWXv1EK7eviAxZpJAOtDe4v_8=.0e521f1c-3187-4bed-a76c-787e9ae2ada7@github.com>

> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
> 
> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.

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/276/files
  - new: https://git.openjdk.org/crac/pull/276/files/e90eac79..a1629ffe

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

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

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

From rvansa at openjdk.org  Thu Jan  8 09:09:54 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 8 Jan 2026 09:09:54 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
Message-ID: <ynyY6_-UPIcEkUmJesqGeFQQovNU7pRP1kNFJ-gfcKE=.3dd6e714-88cf-42b7-8922-5aa50acaac13@github.com>

On Wed, 7 Jan 2026 15:37:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixups

@TimPushkin @jankratochvil Could I get this approved please, or are there further requests for a change?

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

PR Comment: https://git.openjdk.org/crac/pull/285#issuecomment-3722902987

From tpushkin at openjdk.org  Thu Jan  8 09:17:08 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 8 Jan 2026 09:17:08 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
Message-ID: <SIqZht4MwaYeYy0LXA_h37gj3xjf46qd51OH0Itqm5w=.271bebdc-a338-4a2a-8d3a-8bbeaace5132@github.com>

On Wed, 7 Jan 2026 15:37:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixups

Looking at this

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

PR Comment: https://git.openjdk.org/crac/pull/285#issuecomment-3722929480

From tpushkin at openjdk.org  Thu Jan  8 09:47:16 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 8 Jan 2026 09:47:16 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
Message-ID: <E8-wUlWQ0pFAJPbwQEedXm9JDOoKtNPXM07Zm_JB8Kg=.1cb022c7-fe40-4ced-9c9f-778c14d0f7c5@github.com>

On Wed, 7 Jan 2026 15:37:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixups

src/hotspot/share/runtime/arguments.cpp line 584:

> 582:   { "CRaCAllowToSkipCheckpoint",    JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
> 583:   { "CRaCDoThrowCheckpointException", JDK_Version::undefined(), JDK_Version::jdk(25), JDK_Version::jdk(26) },
> 584:   { "IgnoreCPUFeatures",            JDK_Version::jdk(26), JDK_Version::jdk(29), JDK_Version::undefined() },

1. I would really prefer the expiration version to be set because each entry in this least slows down VM option parsing a bit.
2. Obsoleting in 29 seems too generous. Since `IgnoreCPUFeatures` was experimental, per the guide above even obsoleting it right away is acceptable. I would suggest either 26, 27, 28 or 26, 28, 29. As can be seen above, the latter would match what we have been doing historically for non-experimental options.

src/hotspot/share/runtime/arguments.cpp line 4081:

> 4079:     }
> 4080:   }
> 4081: 

Does not matter functionally, but semantically I think this should be in `check_vm_args_consistency` and use `FLAG_SET_CMDLINE` instead of `FLAG_SET_ERGO`.

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

> 821:       log_error(crac)("-XX:CheckCPUFeatures=skip is allowed only with -XX:+UnlockExperimentalVMOptions");
> 822:       return;
> 823:     }

Better to do this in `Arguments::check_vm_args_consistency`

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

> 826:     exact = true;
> 827:   } else if (strcmp(CheckCPUFeatures, "compatible")) {
> 828:     log_error(crac)("Invalid value for -XX:CheckCPUFeatures=%s; available are 'compatible', 'exact' or 'skip'", CheckCPUFeatures);

Nitpick: I think having `CheckCPUFeatures == nullptr || !strcmp(CheckCPUFeatures, "compatible")` as the first check and just `else` here would be more readable

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

PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2671546690
PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2671615423
PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2671626492
PR Review Comment: https://git.openjdk.org/crac/pull/285#discussion_r2671637816

From jkratochvil at openjdk.org  Thu Jan  8 09:54:18 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 8 Jan 2026 09:54:18 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
Message-ID: <Rory9U2gBGD9JekkEfSiaycl1_fyKAJPWQvA4IZsjo8=.6b18e1f1-565e-4605-b3a8-beddd412c4c6@github.com>

On Wed, 7 Jan 2026 15:37:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixups

Marked as reviewed by jkratochvil (no project role).

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

PR Review: https://git.openjdk.org/crac/pull/285#pullrequestreview-3638639598

From jkratochvil at openjdk.org  Thu Jan  8 12:18:04 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 8 Jan 2026 12:18:04 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v3]
In-Reply-To: <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
 <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
Message-ID: <Wpa2ayzz3pXFjl_N8Un841obHwTllJxHmYp1uwdgBmw=.b35735ba-38c5-49db-b199-af67bee1a562@github.com>

On Mon, 5 Jan 2026 21:51:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
>> 
>> On AWS m1.small:
>> 
>> bin/java -XX:+ShowCPUFeatures --version
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> openjdk 25-internal 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
>> 
>> That is a needless re-exec.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' detection

filed: https://bugs.openjdk.org/browse/JDK-8374791 = [CRaC] [test] fileDescriptors/PatchModuleTest: guarantee(-1 != r) failed: can't stat fd

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

PR Comment: https://git.openjdk.org/crac/pull/283#issuecomment-3723597813

From duke at openjdk.org  Thu Jan  8 12:18:04 2026
From: duke at openjdk.org (duke)
Date: Thu, 8 Jan 2026 12:18:04 GMT
Subject: [crac] RFR: 8374491: CPUFeatures: check performance regression of
 AVX_Fast_Unaligned_Load [v3]
In-Reply-To: <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
 <Q1tPAXOu_mvWoO1EYHx_b6xmQ4LBxmkbmJw--FZiEvk=.8e6d3e8f-9a30-4049-b89d-c3b72c2f6163@github.com>
Message-ID: <tz7ODyMPgoBLi0BpgnDZ6qXcGUBlB7mNnWgbCqc4M7s=.329bfd59-d21b-4a8d-aa7d-eadcbd8e40ed@github.com>

On Mon, 5 Jan 2026 21:51:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
>> 
>> On AWS m1.small:
>> 
>> bin/java -XX:+ShowCPUFeatures --version
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
>> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
>> openjdk 25-internal 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
>> 
>> That is a needless re-exec.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the 'xem_xcr0_eax.bits.sse != 0 && xem_xcr0_eax.bits.ymm != 0' detection

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

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

PR Comment: https://git.openjdk.org/crac/pull/283#issuecomment-3723602581

From jkratochvil at openjdk.org  Thu Jan  8 12:49:23 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 8 Jan 2026 12:49:23 GMT
Subject: [crac] Integrated: 8374491: CPUFeatures: check performance regression
 of AVX_Fast_Unaligned_Load
In-Reply-To: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
References: <YT3qQtSVCwr7bs6MYILFUZ380hQZtOGwMl1POsyJI5I=.73cfc567-56af-4741-a9d1-e9d89a17f80e@github.com>
Message-ID: <9VfLElwyZJB0Kw4O3AUwvUcOLj6FSUihTeWy-uEKXBE=.4fcfe523-a073-4630-bbd3-5e1be1118a00@github.com>

On Sun, 4 Jan 2026 23:58:39 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> A regression by [JDK-8372863](https://bugs.openjdk.org/browse/JDK-8372863).
> 
> On AWS m1.small:
> 
> bin/java -XX:+ShowCPUFeatures --version
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> Re-exec of java with new environment variable: GLIBC_TUNABLES=:glibc.cpu.hwcaps=,-AVX_Fast_Unaligned_Load
> This machine's CPU features are: -XX:CPUFeatures=0x142000070bbdf,0x380
> CPU features being used are: -XX:CPUFeatures=0x142000070bbdf,0x380
> openjdk 25-internal 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.azul.crac-git)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.azul.crac-git, mixed mode, sharing)
> 
> That is a needless re-exec.

This pull request has now been integrated.

Changeset: 53d1ac44
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/53d1ac44f921a330029acca99e7ab952cf355acf
Stats:     17 lines in 1 file changed: 4 ins; 6 del; 7 mod

8374491: CPUFeatures: check performance regression of AVX_Fast_Unaligned_Load

Reviewed-by: tpushkin

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

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

From rvansa at openjdk.org  Thu Jan  8 14:06:08 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 8 Jan 2026 14:06:08 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v3]
In-Reply-To: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
Message-ID: <wbeqOqGZAyCtI4s4qXy-zzmXShjYxIlxMJzIMZkXwwQ=.eac44b06-92a5-4a89-98b0-09b48a2bca30@github.com>

> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
> 
> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
> * compatible - this is the current behaviour (default)
> * exact - require CPU features from the image to match perfectly
> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
> 
> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

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

  Move VM options checks

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

Changes:
  - all: https://git.openjdk.org/crac/pull/285/files
  - new: https://git.openjdk.org/crac/pull/285/files/75db21c9..db658c00

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

  Stats: 31 lines in 2 files changed: 16 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/crac/pull/285.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/285/head:pull/285

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

From rvansa at openjdk.org  Thu Jan  8 14:06:11 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 8 Jan 2026 14:06:11 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v2]
In-Reply-To: <SIqZht4MwaYeYy0LXA_h37gj3xjf46qd51OH0Itqm5w=.271bebdc-a338-4a2a-8d3a-8bbeaace5132@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <hRIcpEw5oDbX_89qXK-UF64e01T_10rfOFzKUWs5PDA=.bdc4fcb0-489a-46c8-b4a7-72aaa44007b7@github.com>
 <SIqZht4MwaYeYy0LXA_h37gj3xjf46qd51OH0Itqm5w=.271bebdc-a338-4a2a-8d3a-8bbeaace5132@github.com>
Message-ID: <w4TWiHexshZPWlNpTy3oJ171VpE4jhcwBieyiH3v6t4=.453aa814-ffdd-44c0-8423-e9f8e96c948a@github.com>

On Thu, 8 Jan 2026 09:13:38 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixups
>
> Looking at this

@TimPushkin Updated as requested.

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

PR Comment: https://git.openjdk.org/crac/pull/285#issuecomment-3723993660

From tpushkin at openjdk.org  Thu Jan  8 16:54:02 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 8 Jan 2026 16:54:02 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v2]
In-Reply-To: <-wv8UAhXfptGNxeJoaIqOU9-li0PMmhCCkBpwMjCLGY=.13a76676-0574-42ba-adeb-23467bae5b4d@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <UcDv7qqhsjYJ3_SkN7IlbabR_Qyzl56nTSjrHco5vJc=.5e2b4d4f-623e-4f80-a7fb-f95e0a31ff56@github.com>
 <2xjmqO3jJtkb-06ybAJTYK1pIHd5rQjDLWfvComx1-E=.7b6f337b-fda7-4e7b-8ab3-7d8f1334a707@github.com>
 <-wv8UAhXfptGNxeJoaIqOU9-li0PMmhCCkBpwMjCLGY=.13a76676-0574-42ba-adeb-23467bae5b4d@github.com>
Message-ID: <3_MxxAkTenA94ivTs2TZbHB07qnYZIXzfwfqiKY1Vd8=.41b7397c-c511-41b6-bbfd-2fb7923e5dca@github.com>

On Wed, 7 Jan 2026 18:37:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/crac/ClaimedFDs.java line 89:
>> 
>>> 87:                         assert fileDescriptorAccess.getHandle(entry.getKey()) != -1;
>>> 88:                         // On Windows the native FDs check is a no-op, but we need to set
>>> 89:                         // the FD to prevent assertion failure on Descriptor.getFd()
>> 
>> Maybe allow -1 as a value? Having 0 may be confusing as it is a valid FD value.
>> 
>> In the future, it looks like we need a more general abstraction for FD/handle.
>
> It is strange to allow -1 in a 'valid' Descriptor. And on Linux, which is our 'main' platform this does not happen - I think it is better to keep it this way. I could do `fd = Integer.MAX_VALUE` to differentiate this from stdin = 0.

AFAIU, this is only used for error reporting. In a error message -1 seems more obvious as a placeholder than 0 or the actual value of `Integer.MAX_VALUE`.

But it is not so important, I'm OK with leaving as is.

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

PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2673107564

From tpushkin at openjdk.org  Thu Jan  8 16:54:06 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 8 Jan 2026 16:54:06 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v4]
In-Reply-To: <t3gDhygT32LMJn2SHJRWXv1EK7eviAxZpJAOtDe4v_8=.0e521f1c-3187-4bed-a76c-787e9ae2ada7@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <t3gDhygT32LMJn2SHJRWXv1EK7eviAxZpJAOtDe4v_8=.0e521f1c-3187-4bed-a76c-787e9ae2ada7@github.com>
Message-ID: <a99aiQTil7Jow-TvogbRGSUPTbdUriyyW0SyxhFUrBk=.a6f95248-78bc-47a7-9e01-a0a74fa1dd27@github.com>

On Thu, 8 Jan 2026 07:04:20 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
>> 
>> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixup

test/jdk/jdk/crac/java/nio/channels/Selector/WakeupByTimeoutAfterRestoreTest.java line 45:

> 43:  * @library /test/lib
> 44:  * @build WakeupByTimeoutAfterRestoreTest
> 45:  * @run driver jdk.test.lib.crac.CracTest sun.nio.ch.PollSelectorProvider

All cases where `PollSelectorProvider` is used can be `id=ALT_UNIX` and `requires (os.family != "unix")`

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

PR Review Comment: https://git.openjdk.org/crac/pull/276#discussion_r2673117069

From tpushkin at openjdk.org  Fri Jan  9 06:37:00 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 9 Jan 2026 06:37:00 GMT
Subject: [crac] RFR: 8373784: [CRaC] VM Option to require perfect CPU fit
 [v3]
In-Reply-To: <wbeqOqGZAyCtI4s4qXy-zzmXShjYxIlxMJzIMZkXwwQ=.eac44b06-92a5-4a89-98b0-09b48a2bca30@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
 <wbeqOqGZAyCtI4s4qXy-zzmXShjYxIlxMJzIMZkXwwQ=.eac44b06-92a5-4a89-98b0-09b48a2bca30@github.com>
Message-ID: <jqv5cG5pLv010ae_8BrSgPWDvAEcG7f5EYd2vpHCho0=.20f581f5-d97c-464a-9d69-14cc44b2507d@github.com>

On Thu, 8 Jan 2026 14:06:08 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
>> 
>> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
>> * compatible - this is the current behaviour (default)
>> * exact - require CPU features from the image to match perfectly
>> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
>> 
>> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move VM options checks

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/285#pullrequestreview-3642594937

From tpushkin at openjdk.org  Fri Jan  9 07:17:00 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 9 Jan 2026 07:17:00 GMT
Subject: [crac] RFR: 8374614: [CRaC] Remove defunct fdinfo marking
In-Reply-To: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
References: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
Message-ID: <D0hzkil5dXO9KV75quVAolCvHjmWgvZnGkYtZdtk1m8=.d7cf0ebf-1142-441a-9b19-14e9cf4cc6f4@github.com>

On Tue, 6 Jan 2026 14:21:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When initializing fdinfos, there might be a racy native thread closing FD between enumerating FDs and `readlink /proc/self/fd/XXX`, causing an error and assertion to fail.
> 
> Further looking into the code it seems that the fdinfo::mark is not read since https://github.com/openjdk/crac/commit/4b0dc2dc9722945579c9772b335a44fa79f1729f and therefore the whole check is defunct, and can be removed.

AFAIU this solves or duplicates https://bugs.openjdk.org/browse/JDK-8374791 ? could you link it properly to this bug?

src/hotspot/os/linux/crac_linux.cpp line 57:

> 55:     state_t state;
> 56: 
> 57:     int flags;

While we are at it, looks like this is also unused

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

PR Review: https://git.openjdk.org/crac/pull/284#pullrequestreview-3642657652
PR Review Comment: https://git.openjdk.org/crac/pull/284#discussion_r2675087166

From rvansa at openjdk.org  Fri Jan  9 08:21:08 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 08:21:08 GMT
Subject: [crac] Integrated: 8373784: [CRaC] VM Option to require perfect CPU
 fit
In-Reply-To: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
References: <IQmVq2IbA9VZ5ZRspWmX0WKXuFcnVqrPm7ZJTKdol7s=.d0e61714-8196-4511-bdd9-5563c82574bc@github.com>
Message-ID: <4yCGqLkqr_eqX1qDBI7SopN3WuWIFFRdK0WxpsemP0U=.0907cd9f-ef78-4473-83f0-169eabee9a7b@github.com>

On Tue, 6 Jan 2026 14:41:20 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Right now CRaC will refuse to restore from the image if it is not compatible with current CPU as it assumes extra features. This check can be only relaxed with -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.
> 
> In scenarios with -XX:CRaCIgnoreRestoreIfUnavailable it might be favorable to skip the restore and proceed with running the application from scratch with all CPU features if the image has these restricted. Therefore I propose to create a new option -XX:CheckCPUFeatures with these values:
> * compatible - this is the current behaviour (default)
> * exact - require CPU features from the image to match perfectly
> * skip - the same behaviour as `-XX:+IgnoreCPUFeatures`.
> 
> The current `-XX:+IgnoreCPUFeatures` option will be deprecated.

This pull request has now been integrated.

Changeset: af6c8445
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/af6c8445eff80134cc5c6f814f5c550b3b0f9333
Stats:     155 lines in 9 files changed: 141 ins; 0 del; 14 mod

8373784: [CRaC] VM Option to require perfect CPU fit

Reviewed-by: jkratochvil, tpushkin

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

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

From rvansa at openjdk.org  Fri Jan  9 10:49:53 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 10:49:53 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v5]
In-Reply-To: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
Message-ID: <4qQRj-VUt-UAX_4_g3Hi3XYWKuNXG5W02H9yUJ4ymNU=.6083c8fd-dca4-45fc-a660-2a2a5691770f@github.com>

> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
> 
> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.

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

  Test PollSelector on all unix platforms

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

Changes:
  - all: https://git.openjdk.org/crac/pull/276/files
  - new: https://git.openjdk.org/crac/pull/276/files/a1629ffe..1ec7201c

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

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

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

From rvansa at openjdk.org  Fri Jan  9 11:30:56 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 11:30:56 GMT
Subject: [crac] RFR: 8374614: [CRaC] Remove defunct fdinfo marking [v2]
In-Reply-To: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
References: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
Message-ID: <QxVnuhKGSHOmwKqsuPn-HN9CkfZz0eoZHuumlZFHOTQ=.617d7524-1392-4e9e-8ba3-a37a920cb4de@github.com>

> When initializing fdinfos, there might be a racy native thread closing FD between enumerating FDs and `readlink /proc/self/fd/XXX`, causing an error and assertion to fail.
> 
> Further looking into the code it seems that the fdinfo::mark is not read since https://github.com/openjdk/crac/commit/4b0dc2dc9722945579c9772b335a44fa79f1729f and therefore the whole check is defunct, and can be removed.

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

  Remove unused flags field

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

Changes:
  - all: https://git.openjdk.org/crac/pull/284/files
  - new: https://git.openjdk.org/crac/pull/284/files/29bd3983..ce2ce45f

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

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

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

From rvansa at openjdk.org  Fri Jan  9 12:09:29 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 12:09:29 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v5]
In-Reply-To: <4qQRj-VUt-UAX_4_g3Hi3XYWKuNXG5W02H9yUJ4ymNU=.6083c8fd-dca4-45fc-a660-2a2a5691770f@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <4qQRj-VUt-UAX_4_g3Hi3XYWKuNXG5W02H9yUJ4ymNU=.6083c8fd-dca4-45fc-a660-2a2a5691770f@github.com>
Message-ID: <u9nqlPHxEDkD0Pig1cL-DdzVvamggsGL5v-b6WpDQJU=.fc1a368d-eeae-46de-8d27-e8daafcec25a@github.com>

On Fri, 9 Jan 2026 10:49:53 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
>> 
>> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test PollSelector on all unix platforms

Failure in `JdwpTransportTest` is unrelated.

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

PR Comment: https://git.openjdk.org/crac/pull/276#issuecomment-3728645959

From rvansa at openjdk.org  Fri Jan  9 12:56:48 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 12:56:48 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v6]
In-Reply-To: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
Message-ID: <npvVvboOs5nf-fR8K_Wyv5EZdx1QErLmv-j5P3dEooQ=.a0441baf-0358-4e47-b50c-874e4c83441c@github.com>

> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
> 
> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.

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/276/files
  - new: https://git.openjdk.org/crac/pull/276/files/1ec7201c..c6e6799f

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

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

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

From tpushkin at openjdk.org  Fri Jan  9 13:00:38 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 9 Jan 2026 13:00:38 GMT
Subject: [crac] RFR: 8374614: [CRaC] Remove defunct fdinfo marking [v2]
In-Reply-To: <QxVnuhKGSHOmwKqsuPn-HN9CkfZz0eoZHuumlZFHOTQ=.617d7524-1392-4e9e-8ba3-a37a920cb4de@github.com>
References: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
 <QxVnuhKGSHOmwKqsuPn-HN9CkfZz0eoZHuumlZFHOTQ=.617d7524-1392-4e9e-8ba3-a37a920cb4de@github.com>
Message-ID: <TBO85QXnY3_qy-FaRYGn4kzhOy1vYtpRoPSMwHHJeSg=.d7936075-491a-4f48-a50f-585ff417aaf4@github.com>

On Fri, 9 Jan 2026 11:30:56 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> When initializing fdinfos, there might be a racy native thread closing FD between enumerating FDs and `readlink /proc/self/fd/XXX`, causing an error and assertion to fail.
>> 
>> Further looking into the code it seems that the fdinfo::mark is not read since https://github.com/openjdk/crac/commit/4b0dc2dc9722945579c9772b335a44fa79f1729f and therefore the whole check is defunct, and can be removed.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused flags field

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/284#pullrequestreview-3643831754

From tpushkin at openjdk.org  Fri Jan  9 13:02:27 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 9 Jan 2026 13:02:27 GMT
Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux
 [v6]
In-Reply-To: <npvVvboOs5nf-fR8K_Wyv5EZdx1QErLmv-j5P3dEooQ=.a0441baf-0358-4e47-b50c-874e4c83441c@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
 <npvVvboOs5nf-fR8K_Wyv5EZdx1QErLmv-j5P3dEooQ=.a0441baf-0358-4e47-b50c-874e4c83441c@github.com>
Message-ID: <YOZv4tlsFve8tC9PjlA_hVOyDgy-FfiE7PZqhKkKuYM=.80251cf6-d9f0-42c2-9fe0-76333ee39fe8@github.com>

On Fri, 9 Jan 2026 12:56:48 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
>> 
>> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixup

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/276#pullrequestreview-3643840642

From rvansa at openjdk.org  Fri Jan  9 14:58:54 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 14:58:54 GMT
Subject: [crac] Integrated: 8371549: [CRaC] Implement C/R in Selector on
 non-Linux
In-Reply-To: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
References: <k_mF4rCk7QXqp7BEYRHY5Poymu2rXfAynJDofj7vFWw=.164bc982-cc53-412c-81d6-622b125506d3@github.com>
Message-ID: <iFdbKI01X9trPH0DpGBsy4tdmRDNipxPdQa5DUzRnH4=.796fd72a-8a10-4d1d-99f4-a0a438527d95@github.com>

On Fri, 28 Nov 2025 15:49:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl.
> 
> This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations.

This pull request has now been integrated.

Changeset: 4b84ed34
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/4b84ed3477670c65ba6775ba80390dda05752be3
Stats:     3765 lines in 37 files changed: 2149 ins; 1543 del; 73 mod

8371549: [CRaC] Implement C/R in Selector on non-Linux

Reviewed-by: tpushkin

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

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

From rvansa at openjdk.org  Fri Jan  9 14:59:03 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 9 Jan 2026 14:59:03 GMT
Subject: [crac] Integrated: 8374614: [CRaC] Remove defunct fdinfo marking
In-Reply-To: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
References: <-zakCWMlAyqReGbRPyID5Rxkas90GnEUYefazuk3pJg=.6f930f60-cee2-4109-8650-44792545c3e1@github.com>
Message-ID: <tfFiUiL-uJ96LziVuxI5eL2nW8ETaUWpgImqSDFxOS4=.eb2456e2-882c-4f32-9d6e-c851c2065df5@github.com>

On Tue, 6 Jan 2026 14:21:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When initializing fdinfos, there might be a racy native thread closing FD between enumerating FDs and `readlink /proc/self/fd/XXX`, causing an error and assertion to fail.
> 
> Further looking into the code it seems that the fdinfo::mark is not read since https://github.com/openjdk/crac/commit/4b0dc2dc9722945579c9772b335a44fa79f1729f and therefore the whole check is defunct, and can be removed.

This pull request has now been integrated.

Changeset: 229431db
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/229431db7276118ec1bb9608fa1194b171df07ec
Stats:     45 lines in 1 file changed: 0 ins; 45 del; 0 mod

8374614: [CRaC] Remove defunct fdinfo marking

Reviewed-by: tpushkin

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

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