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

From rvansa at openjdk.org  Mon Jan 12 14:45:46 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 12 Jan 2026 14:45:46 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info
Message-ID: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>

Currently the engine documents all exposed options through the description extension; this has some downsides:

* when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
* options completely controlled by JVM (such as image_location) are reported, too
* options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)

The solution is exposing options info in a more structured manner.

As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

Commit messages:
 - 8375044: [CRaC] Structured engine options info

Changes: https://git.openjdk.org/crac/pull/286/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375044
  Stats: 195 lines in 7 files changed: 128 ins; 24 del; 43 mod
  Patch: https://git.openjdk.org/crac/pull/286.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/286/head:pull/286

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

From rvansa at openjdk.org  Mon Jan 12 17:28:53 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 12 Jan 2026 17:28:53 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v2]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <i-G_beSYBwZDtG0oJo9n47X1rq4kuqFT-sQ8fmGqbcI=.be248969-e483-46ec-8a48-aed25eac183b@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

  Turn deprecation into flag, fix ParsingTest

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

Changes:
  - all: https://git.openjdk.org/crac/pull/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/cb8d49c8..a9864c5a

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

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

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

From rvansa at openjdk.org  Tue Jan 13 07:01:34 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 13 Jan 2026 07:01:34 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v3]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <LmFWnOLuPCM_TJiaqIrElgaBWOUx8eiIO0SxCCorko8=.875f6a11-0584-45c1-b619-fce55e41348d@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

  Remove NULL usages

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

Changes:
  - all: https://git.openjdk.org/crac/pull/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/a9864c5a..ed2ca146

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

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

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

From rvansa at openjdk.org  Wed Jan 14 07:26:51 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 14 Jan 2026 07:26:51 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

  Fix windows build

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

Changes:
  - all: https://git.openjdk.org/crac/pull/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/ed2ca146..8c470cf4

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

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

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

From rvansa at openjdk.org  Wed Jan 14 11:27:20 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 14 Jan 2026 11:27:20 GMT
Subject: [crac] RFR: 8375286: [CRaC] Crash with empty CRaCCheckpointTo
Message-ID: <JAAPgIFOzA7g2uIKvTMwCsar2E-MOkWx_m8hJJG5bwo=.91dc187b-c9ba-4ffb-89a1-d9dc6282de38@github.com>

When the JVM is started with `-XX:CRaCCheckpointTo=` (empty value), on checkpoint the code accesses null pointer and the process crashes.

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

Commit messages:
 - 8375286: [CRaC] Crash with empty CRaCCheckpointTo

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

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

From tpushkin at openjdk.org  Mon Jan 19 08:30:13 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 Jan 2026 08:30:13 GMT
Subject: [crac] RFR: 8375286: [CRaC] Crash with empty CRaCCheckpointTo
In-Reply-To: <JAAPgIFOzA7g2uIKvTMwCsar2E-MOkWx_m8hJJG5bwo=.91dc187b-c9ba-4ffb-89a1-d9dc6282de38@github.com>
References: <JAAPgIFOzA7g2uIKvTMwCsar2E-MOkWx_m8hJJG5bwo=.91dc187b-c9ba-4ffb-89a1-d9dc6282de38@github.com>
Message-ID: <YzyPtFhZl-rdH4vCBg8Ze7ilnVoSDG-kkcMlg7Fwp2Y=.18c46cd6-1bc5-4087-b9ac-4f8585ebc855@github.com>

On Wed, 14 Jan 2026 11:20:17 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When the JVM is started with `-XX:CRaCCheckpointTo=` (empty value), on checkpoint the code accesses null pointer and the process crashes.

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/287#pullrequestreview-3676870377

From rvansa at openjdk.org  Mon Jan 19 08:31:48 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 19 Jan 2026 08:31:48 GMT
Subject: [crac] Integrated: 8375286: [CRaC] Crash with empty CRaCCheckpointTo
In-Reply-To: <JAAPgIFOzA7g2uIKvTMwCsar2E-MOkWx_m8hJJG5bwo=.91dc187b-c9ba-4ffb-89a1-d9dc6282de38@github.com>
References: <JAAPgIFOzA7g2uIKvTMwCsar2E-MOkWx_m8hJJG5bwo=.91dc187b-c9ba-4ffb-89a1-d9dc6282de38@github.com>
Message-ID: <CK9Ig5dzhXNB0x5SDKf_vTW_vD5b6VYQ5g2K4Npc0gE=.acf0d9f9-bd9d-4ded-95d9-c946dc55d6f9@github.com>

On Wed, 14 Jan 2026 11:20:17 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When the JVM is started with `-XX:CRaCCheckpointTo=` (empty value), on checkpoint the code accesses null pointer and the process crashes.

This pull request has now been integrated.

Changeset: 9616024a
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/9616024ab597223be84c8d318cc1ee4379f307af
Stats:     157 lines in 5 files changed: 150 ins; 0 del; 7 mod

8375286: [CRaC] Crash with empty CRaCCheckpointTo

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Mon Jan 19 10:29:13 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 Jan 2026 10:29:13 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
Message-ID: <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>

On Wed, 14 Jan 2026 07:26:51 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Currently the engine documents all exposed options through the description extension; this has some downsides:
>> 
>> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
>> * options completely controlled by JVM (such as image_location) are reported, too
>> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
>> 
>> The solution is exposing options info in a more structured manner.
>> 
>> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows build

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

> 35: 
> 36: // Applicability of the option: setting the value in non-applicable context
> 37: // may result in warnings or errors.

I don't think `DEPRECATED` is about applicability, at least not in the same sense as the other two flags are. Maybe the docs should be separate for each flag?

src/hotspot/share/include/crlib/crlib_description.h line 41:

> 39:   CHECKPOINT = 1 << 0,
> 40:   RESTORE    = 1 << 1,
> 41:   DEPRECATED = 1 << 2,

The values should have globally unique names, like `CRLIB_CONF_OPTION_FLAG_CHECKPOINT`.

E.g. we have `CRLIB_IMAGE_INFO_*` prefix for `crlib_image_info_parts_t` enum in the image info extension of Zulu.

src/hotspot/share/include/crlib/crlib_description.h line 42:

> 40:   RESTORE    = 1 << 1,
> 41:   DEPRECATED = 1 << 2,
> 42: } crlib_conf_option_flag_t;

There may be a problem with ABI compatibility if we'll add more values in the future. Since we do not fix an underlying type (we cannot as this is a C99 API) the compiler is free to choose any integer type not larger than int that can represent all listed values. I suggest adding an upper-bound value that will ensure that either int or unsigned int is the underlying type and only unsigned values are used (on popular data models): `MAX = 0x7FFFFFFF`. The value is not supposed to be actually used.

Although maybe this is too paranoid.

src/hotspot/share/include/crlib/crlib_description.h line 50:

> 48:   const char *value_type;
> 49:   const char *default_value;
> 50:   const char *description;

I'd prefer to have nullability specified for the strings. I think all but `default_value` must be non-nullable. `default_value` probably should be nullable with null representing options without which the engine will always fail C/R (e.g. image and engine locations in case of crexec).

src/hotspot/share/include/crlib/crlib_description.h line 72:

> 70:   // Some keys can be excluded if these are not supposed to be set by a user but rather by the
> 71:   // application the engine is linked to, or if these are deprecated.
> 72:   //

For compatibility we shouldn't change existing API like this. But we can add a deprecation note for the method suggesting switching to the new `configuration_options` method.

src/hotspot/share/include/crlib/crlib_description.h line 89:

> 87:   // Returns an array of all configuration options supported by the engine.
> 88:   // The array is terminated with an option with null key.
> 89:   // Set to null if this method is not supported.

We decided against allowing nulls for unsupported methods. Instead, the app should not use methods that are defined beyond `extension->header.size`, and the engine should return an error value (null in this case) when the method exists in the API, is called, but the engine does not support it.

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

> 551:   } else {
> 552:     if (pattern != nullptr) {
> 553:       log_warning(crac)("Option filtering by pattern not available");

Would be cleaner to print `Configuration options:` instead of `Configuration options matching *%s*:` ? just a matter of moving the printing under the `options != nullptr` check

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

> 407:   require_method(configurable_keys)
> 408:   require_method(supported_extensions)
> 409:   // configuration_options is not mandatory

We should rely on `_description_api->header.size` instead

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

> 422: 
> 423: const crlib_conf_option_t *CracEngine::configuration_options() const {
> 424:   static crlib_conf_option_t *all_options = nullptr;

I doubt that the documentation code will be performance-critical so I'd prefer to remove this caching to leave the possibility of using `CracEngine` for different engines within a process. I don't have a practical use case yet, just seems cleaner.

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

> 438:   crlib_conf_option_t *dst = all_options;
> 439:   for (src = options; src->key != nullptr; ++src, ++dst) {
> 440:     memcpy(dst, src, sizeof(*src));

Better to copy after the skip check

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

> 201: #undef ADD_ARR_ELEM
> 202: #define ADD_ARR_ELEM(id, ctype, cdef, flags, ...) { opt_##id, static_cast<crlib_conf_option_flag_t>(flags), __VA_ARGS__ },
> 203: static const crlib_conf_option_t configure_options[] = { CONFIGURE_OPTIONS(ADD_ARR_ELEM) {} };

Can't the arrays still be constexpr?

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

> 246:   };
> 247: 
> 248: // Note: image_location, exec_location and args from this are ignored

Maybe split `CONFIGURE_OPTIONS` onto `CHECKED_OPTIONS` (w/ a field) and `UNCHECKED_OPTIONS` (w/o a field)? Otherwise the majority of the fields created here are redundant.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703871002
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703856219
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703846454
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703930933
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703942271
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703960918
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704013689
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704044221
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704055572
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704076415
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704110480
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2704128290

From tpushkin at openjdk.org  Mon Jan 19 10:29:15 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 19 Jan 2026 10:29:15 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
Message-ID: <6Hip3oVa-M0kmK3K6fRwUZkavaO96Zdlvz3pOb-bmgw=.330bd605-a0d9-4b49-92e0-6a20b9caf8f7@github.com>

On Mon, 19 Jan 2026 09:05:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/share/include/crlib/crlib_description.h line 41:
> 
>> 39:   CHECKPOINT = 1 << 0,
>> 40:   RESTORE    = 1 << 1,
>> 41:   DEPRECATED = 1 << 2,
> 
> The values should have globally unique names, like `CRLIB_CONF_OPTION_FLAG_CHECKPOINT`.
> 
> E.g. we have `CRLIB_IMAGE_INFO_*` prefix for `crlib_image_info_parts_t` enum in the image info extension of Zulu.

We already have the same problem with `crlib_bitmap_comparison_t`...

> src/hotspot/share/include/crlib/crlib_description.h line 42:
> 
>> 40:   RESTORE    = 1 << 1,
>> 41:   DEPRECATED = 1 << 2,
>> 42: } crlib_conf_option_flag_t;
> 
> There may be a problem with ABI compatibility if we'll add more values in the future. Since we do not fix an underlying type (we cannot as this is a C99 API) the compiler is free to choose any integer type not larger than int that can represent all listed values. I suggest adding an upper-bound value that will ensure that either int or unsigned int is the underlying type and only unsigned values are used (on popular data models): `MAX = 0x7FFFFFFF`. The value is not supposed to be actually used.
> 
> Although maybe this is too paranoid.

If we choose to apply this, the same should be done for `crlib_bitmap_comparison_t`

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703883123
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2703893116

From rvansa at openjdk.org  Tue Jan 20 14:48:28 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 14:48:28 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <6Hip3oVa-M0kmK3K6fRwUZkavaO96Zdlvz3pOb-bmgw=.330bd605-a0d9-4b49-92e0-6a20b9caf8f7@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
 <6Hip3oVa-M0kmK3K6fRwUZkavaO96Zdlvz3pOb-bmgw=.330bd605-a0d9-4b49-92e0-6a20b9caf8f7@github.com>
Message-ID: <EV3q0D4ggY81PYrtS2q57pJFrOs3SxooRw3m36EwNMU=.fb770033-e494-4509-afaa-7ef42734415a@github.com>

On Mon, 19 Jan 2026 09:15:54 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/hotspot/share/include/crlib/crlib_description.h line 42:
>> 
>>> 40:   RESTORE    = 1 << 1,
>>> 41:   DEPRECATED = 1 << 2,
>>> 42: } crlib_conf_option_flag_t;
>> 
>> There may be a problem with ABI compatibility if we'll add more values in the future. Since we do not fix an underlying type (we cannot as this is a C99 API) the compiler is free to choose any integer type not larger than int that can represent all listed values. I suggest adding an upper-bound value that will ensure that either int or unsigned int is the underlying type and only unsigned values are used (on popular data models): `MAX = 0x7FFFFFFF`. The value is not supposed to be actually used.
>> 
>> Although maybe this is too paranoid.
>
> If we choose to apply this, the same should be done for `crlib_bitmap_comparison_t`

OK, you convinced me that C's enums are not good for ABI compatilibility, and are annoying as these need to be globally unique identifiers.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2708667106

From rvansa at openjdk.org  Tue Jan 20 15:52:05 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 15:52:05 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
Message-ID: <-iRZI3z0AUrxW6BJ54GROsPQITKwHdn9OsEmlv2uNJQ=.1b07c7fe-30eb-4f83-ab5a-9fcf2b3cee51@github.com>

On Mon, 19 Jan 2026 09:58:58 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/share/runtime/crac_engine.cpp line 424:
> 
>> 422: 
>> 423: const crlib_conf_option_t *CracEngine::configuration_options() const {
>> 424:   static crlib_conf_option_t *all_options = nullptr;
> 
> I doubt that the documentation code will be performance-critical so I'd prefer to remove this caching to leave the possibility of using `CracEngine` for different engines within a process. I don't have a practical use case yet, just seems cleaner.

This is not only about caching, but also about managing the lifecycle, any symmetry with `configuration_doc` (which is not released by the caller).  But I can keep the cache in `CRaCEngine`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2708958151

From rvansa at openjdk.org  Tue Jan 20 16:15:54 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 16:15:54 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v5]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <7hyA3nm-F1m_atVlhJkYcGUeuD0Pl3P355bBNdXVEac=.32e389d7-9ab9-41c6-8e2f-32cb398bc7b4@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/8c470cf4..87a6cae4

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

  Stats: 77 lines in 5 files changed: 30 ins; 10 del; 37 mod
  Patch: https://git.openjdk.org/crac/pull/286.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/286/head:pull/286

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

From rvansa at openjdk.org  Tue Jan 20 16:16:04 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 16:16:04 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
Message-ID: <CG-5ufNXZepf4MBOV66qEnbWJeKiezTf2iAALXlcQB0=.49ad9c7c-ebfa-4241-ab5c-bf8423a68d8a@github.com>

On Mon, 19 Jan 2026 09:29:44 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/share/include/crlib/crlib_description.h line 72:
> 
>> 70:   // Some keys can be excluded if these are not supposed to be set by a user but rather by the
>> 71:   // application the engine is linked to, or if these are deprecated.
>> 72:   //
> 
> For compatibility we shouldn't change existing API like this. But we can add a deprecation note for the method suggesting switching to the new `configuration_options` method.

I think this is rather clarification of the API.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2709059999

From rvansa at openjdk.org  Tue Jan 20 16:24:20 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 16:24:20 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v6]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <cLQZe3ENuDDbkJ4lNd0z7lIpqVyljnTd8PgL4-3EeDQ=.f815069e-429d-43d1-a360-0ad53db86de0@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

  Fix long line

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

Changes:
  - all: https://git.openjdk.org/crac/pull/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/87a6cae4..49407b6c

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

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

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

From rvansa at openjdk.org  Tue Jan 20 16:24:25 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 16:24:25 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <ZnzuztFb1zu7URpBUR9TFsSbEwQhJ-zPavgyAUSaZyk=.8c36def2-9b07-4813-95a0-c52431e90473@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
 <ZnzuztFb1zu7URpBUR9TFsSbEwQhJ-zPavgyAUSaZyk=.8c36def2-9b07-4813-95a0-c52431e90473@github.com>
Message-ID: <ePA16X75RW6MthrFhf4NGocwRfqicahbmiN6q8UgpIY=.ba838151-af64-4412-a2b7-8fb37846f6c1@github.com>

On Tue, 20 Jan 2026 16:20:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/include/crlib/crlib_description.h line 50:
>> 
>>> 48:   const char *value_type;
>>> 49:   const char *default_value;
>>> 50:   const char *description;
>> 
>> I'd prefer to have nullability specified for the strings. I think all but `default_value` must be non-nullable. `default_value` probably should be nullable with null representing options without which the engine will always fail C/R (e.g. image and engine locations in case of crexec).
>
> I don't think we need the special `null` case for must-be-set option; it's better to document that there's no default value.

(I've made all of those non-nullable)

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2709093298

From rvansa at openjdk.org  Tue Jan 20 16:24:24 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 20 Jan 2026 16:24:24 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
Message-ID: <ZnzuztFb1zu7URpBUR9TFsSbEwQhJ-zPavgyAUSaZyk=.8c36def2-9b07-4813-95a0-c52431e90473@github.com>

On Mon, 19 Jan 2026 09:26:45 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/share/include/crlib/crlib_description.h line 50:
> 
>> 48:   const char *value_type;
>> 49:   const char *default_value;
>> 50:   const char *description;
> 
> I'd prefer to have nullability specified for the strings. I think all but `default_value` must be non-nullable. `default_value` probably should be nullable with null representing options without which the engine will always fail C/R (e.g. image and engine locations in case of crexec).

I don't think we need the special `null` case for must-be-set option; it's better to document that there's no default value.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2709091431

From tpushkin at openjdk.org  Thu Jan 22 07:07:00 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 22 Jan 2026 07:07:00 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v4]
In-Reply-To: <-iRZI3z0AUrxW6BJ54GROsPQITKwHdn9OsEmlv2uNJQ=.1b07c7fe-30eb-4f83-ab5a-9fcf2b3cee51@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <7YC183B_MUEReHekdXgyu1ShtdxoEOdrclPBiHP2WLQ=.c618270f-bc0f-4ca9-b969-7f1f006de719@github.com>
 <6Z_uFGL_vysF6QPn15YC_WElKSJllcXlh43aEr7E51E=.4aa15d2c-61fc-40f9-b536-6a64b8bff3b1@github.com>
 <-iRZI3z0AUrxW6BJ54GROsPQITKwHdn9OsEmlv2uNJQ=.1b07c7fe-30eb-4f83-ab5a-9fcf2b3cee51@github.com>
Message-ID: <teomeE-U2LI8E9MWVgfIx8jhYA0lCMLFUNkrElATOwE=.827d213e-9958-47dc-9b5d-b62cd01ee00f@github.com>

On Tue, 20 Jan 2026 15:49:27 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac_engine.cpp line 424:
>> 
>>> 422: 
>>> 423: const crlib_conf_option_t *CracEngine::configuration_options() const {
>>> 424:   static crlib_conf_option_t *all_options = nullptr;
>> 
>> I doubt that the documentation code will be performance-critical so I'd prefer to remove this caching to leave the possibility of using `CracEngine` for different engines within a process. I don't have a practical use case yet, just seems cleaner.
>
> This is not only about caching, but also about managing the lifecycle, any symmetry with `configuration_doc` (which is not released by the caller).  But I can keep the cache in `CRaCEngine`.

`CRaCEngine`'s methods do not have to follow exactly the same semantics as the corresponding crlib methods so I expected it would be the caller's responsibility to free. But the current approach is also OK.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2715584719

From tpushkin at openjdk.org  Thu Jan 22 07:26:02 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 22 Jan 2026 07:26:02 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v6]
In-Reply-To: <cLQZe3ENuDDbkJ4lNd0z7lIpqVyljnTd8PgL4-3EeDQ=.f815069e-429d-43d1-a360-0ad53db86de0@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <cLQZe3ENuDDbkJ4lNd0z7lIpqVyljnTd8PgL4-3EeDQ=.f815069e-429d-43d1-a360-0ad53db86de0@github.com>
Message-ID: <K8k-Dkwy2hdigqnWoghddFyP_2DvXK6e8fPc98iKvrs=.16bc5394-7f39-4e3f-9a2a-67ab05d8ed89@github.com>

On Tue, 20 Jan 2026 16:24:20 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Currently the engine documents all exposed options through the description extension; this has some downsides:
>> 
>> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
>> * options completely controlled by JVM (such as image_location) are reported, too
>> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
>> 
>> The solution is exposing options info in a more structured manner.
>> 
>> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix long line

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

> 232: }
> 233: 
> 234: CracEngine::CracEngine(): _options(nullptr) {

Redundant with `_options = nullptr` in the header.
Suggestion:

CracEngine::CracEngine() {

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

> 88:   crlib_image_score_t *_image_score_api = nullptr;
> 89: 
> 90:   crlib_conf_option_t *_options;

Suggestion:

  crlib_conf_option_t *_options = nullptr;

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

> 185:   OPT(image_location, const char *, nullptr, CRLIB_OPTION_FLAG_CHECKPOINT | CRLIB_OPTION_FLAG_RESTORE, "path", "no default", \
> 186:     "path to a directory with checkpoint/restore files.") \
> 187:   OPT(exec_location, const char *, nullptr, CRLIB_OPTION_FLAG_CHECKPOINT | CRLIB_OPTION_FLAG_RESTORE, "path", "no default", \

Nitpick: by using `"no default"` we don't follow our own recommendation from the API to "use empty string" when there's no default. I'm not sure which version is better.

I suggested making this nullable to have uniformity across engines (it would be up to the JVM to choose how to present this), but maybe it's indeed better to leave this up to engine devs.

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2715634408
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2715632314
PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2715607405

From rvansa at openjdk.org  Thu Jan 22 09:03:51 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 22 Jan 2026 09:03:51 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v7]
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <rgkakegYPdr06r5I7-oLfvRFeepzAHOlpHDvFCJ34QU=.3ecbb072-53ec-48c8-8de6-8a232ac693f5@github.com>

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

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

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

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

Changes:
  - all: https://git.openjdk.org/crac/pull/286/files
  - new: https://git.openjdk.org/crac/pull/286/files/49407b6c..b4e1cb4a

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

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

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

From rvansa at openjdk.org  Thu Jan 22 09:07:56 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 22 Jan 2026 09:07:56 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v6]
In-Reply-To: <K8k-Dkwy2hdigqnWoghddFyP_2DvXK6e8fPc98iKvrs=.16bc5394-7f39-4e3f-9a2a-67ab05d8ed89@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <cLQZe3ENuDDbkJ4lNd0z7lIpqVyljnTd8PgL4-3EeDQ=.f815069e-429d-43d1-a360-0ad53db86de0@github.com>
 <K8k-Dkwy2hdigqnWoghddFyP_2DvXK6e8fPc98iKvrs=.16bc5394-7f39-4e3f-9a2a-67ab05d8ed89@github.com>
Message-ID: <tTIO4wOM1tl5Nd5soInug_1Ruj5JdSpOriEH_3tMKEo=.b650ab26-4734-4229-87ad-c60099f4a448@github.com>

On Thu, 22 Jan 2026 07:11:37 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix long line
>
> src/java.base/share/native/libcrexec/crexec.cpp line 187:
> 
>> 185:   OPT(image_location, const char *, nullptr, CRLIB_OPTION_FLAG_CHECKPOINT | CRLIB_OPTION_FLAG_RESTORE, "path", "no default", \
>> 186:     "path to a directory with checkpoint/restore files.") \
>> 187:   OPT(exec_location, const char *, nullptr, CRLIB_OPTION_FLAG_CHECKPOINT | CRLIB_OPTION_FLAG_RESTORE, "path", "no default", \
> 
> Nitpick: by using `"no default"` we don't follow our own recommendation from the API to "use empty string" when there's no default. I'm not sure which version is better.
> 
> I suggested making this nullable to have uniformity across engines (it would be up to the JVM to choose how to present this), but maybe it's indeed better to leave this up to engine devs.

The doc does not say that it should be an empty string when there's no default, only in cases where you'd put `NULL` :) The reason I've stayed with `no default` in here is the presentation: the engine does not parse the declared 'default' value, and when this is printed with `help` it would look better. Although wait a sec, we're not printing this anymore...

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

PR Review Comment: https://git.openjdk.org/crac/pull/286#discussion_r2715968411

From rvansa at openjdk.org  Fri Jan 23 13:15:27 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 23 Jan 2026 13:15:27 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v7]
In-Reply-To: <rgkakegYPdr06r5I7-oLfvRFeepzAHOlpHDvFCJ34QU=.3ecbb072-53ec-48c8-8de6-8a232ac693f5@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <rgkakegYPdr06r5I7-oLfvRFeepzAHOlpHDvFCJ34QU=.3ecbb072-53ec-48c8-8de6-8a232ac693f5@github.com>
Message-ID: <Z5geLGOC6KtUzXQUlCtYUaNKq70vUQG0LxrAcB--o6k=.142e4ebd-40d0-4158-a1a2-ecfd9aa48a8f@github.com>

On Thu, 22 Jan 2026 09:03:51 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Currently the engine documents all exposed options through the description extension; this has some downsides:
>> 
>> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
>> * options completely controlled by JVM (such as image_location) are reported, too
>> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
>> 
>> The solution is exposing options info in a more structured manner.
>> 
>> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Move _options intitialization
>   
>   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>

@TimPushkin Do you expect me to apply any further changes?

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

PR Comment: https://git.openjdk.org/crac/pull/286#issuecomment-3790176057

From tpushkin at openjdk.org  Fri Jan 23 13:22:15 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 23 Jan 2026 13:22:15 GMT
Subject: [crac] RFR: 8375044: [CRaC] Structured engine options info [v7]
In-Reply-To: <rgkakegYPdr06r5I7-oLfvRFeepzAHOlpHDvFCJ34QU=.3ecbb072-53ec-48c8-8de6-8a232ac693f5@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
 <rgkakegYPdr06r5I7-oLfvRFeepzAHOlpHDvFCJ34QU=.3ecbb072-53ec-48c8-8de6-8a232ac693f5@github.com>
Message-ID: <VIMcBUQdAIFVALszm5tCq-nWqpM-IPjKVnQBkAs37SQ=.63597437-ce44-41af-9a44-09f37746b63e@github.com>

On Thu, 22 Jan 2026 09:03:51 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Currently the engine documents all exposed options through the description extension; this has some downsides:
>> 
>> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
>> * options completely controlled by JVM (such as image_location) are reported, too
>> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
>> 
>> The solution is exposing options info in a more structured manner.
>> 
>> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Move _options intitialization
>   
>   Co-authored-by: Timofei Pushkin <pushkin.td at gmail.com>

Marked as reviewed by tpushkin (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/286#pullrequestreview-3697440272

From rvansa at openjdk.org  Mon Jan 26 07:53:23 2026
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 26 Jan 2026 07:53:23 GMT
Subject: [crac] Integrated: 8375044: [CRaC] Structured engine options info
In-Reply-To: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
References: <1Uw17bPNUXgLPiyClaegyOfIkKRELT6dRSV3pTIBvAs=.e846ab81-2514-4274-acc5-631506e8d4e3@github.com>
Message-ID: <RpA5EBh0fgCPO1bdFts5H5Zu2FL8aYRMtThu0bPyrBQ=.e6021e5c-db3f-4a8f-8d7f-54680cf350ee@github.com>

On Mon, 12 Jan 2026 14:35:48 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Currently the engine documents all exposed options through the description extension; this has some downsides:
> 
> * when the JVM wants to change engine option default, -XX:CRaCEngineOptions=help would print wrong value
> * options completely controlled by JVM (such as image_location) are reported, too
> * options documentation format is fully up to the engine (and it would be more complicated to reflow lines in the output)
> 
> The solution is exposing options info in a more structured manner.
> 
> As an extra feature we can use -XX:CRaCEngineOptions=help=foo to limit help to only those containing 'foo' in the name.

This pull request has now been integrated.

Changeset: 25d6782a
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/25d6782a1c26965f21b62638213d9a9cedd75004
Stats:     236 lines in 8 files changed: 164 ins; 26 del; 46 mod

8375044: [CRaC] Structured engine options info

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Wed Jan 28 08:27:52 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 28 Jan 2026 08:27:52 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5
Message-ID: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>

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

Currently two tests that use images from https://github.com/CRaC/container-images fail in CI because the glibc-based image needs to be updated (CI now uses glibc 2.38) ? I am working on that in that repo, no related changes in this repo are expected.

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

Commit messages:
 - Merge tag 'jdk-27+5' into merge-jdk-27+5
 - 8354853: Clean up x86 registers after 32-bit x86 removal
 - 8373134: C2: Min/Max users of Min/Max uses should be enqueued for GVN
 - 8371762: Incorrect use of checked_cast in Arguments::process_settings_file
 - 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages
 - 8374879: NMethodRelocationTest fails with -Xcomp after 8369150
 - 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests
 - 8374432: TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with -Xcomp
 - 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException
 - 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package
 - ... and 2917 more: https://git.openjdk.org/crac/compare/9616024a...f493f95e

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

Changes: https://git.openjdk.org/crac/pull/288/files
  Stats: 825699 lines in 10640 files changed: 544358 ins; 173424 del; 107917 mod
  Patch: https://git.openjdk.org/crac/pull/288.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/288/head:pull/288

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

From tpushkin at openjdk.org  Wed Jan 28 08:27:53 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 28 Jan 2026 08:27:53 GMT
Subject: [crac] RFR: 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: <oxX7iIj9axNXXZpC1RfjosQsfugPQCBbIl4xYVCHeGA=.1b3a1f4f-6fe5-4a68-b54b-eec0bcb0fc8d@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
> 
> Currently two tests that use images from https://github.com/CRaC/container-images fail in CI because the glibc-based image needs to be updated (CI now uses glibc 2.38) ? I am working on that in that repo, no related changes in this repo are expected.

@jankratochvil I can't assign you as a reviewer, but please review the changes related to CPU features, the handling of the new `HYBRID` feature in particular

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

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

From jkratochvil at openjdk.org  Wed Jan 28 10:43:26 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 28 Jan 2026 10:43:26 GMT
Subject: [crac] RFR: 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: <E9Ox628kni-hbWSvI7-jxYHUiI2qQTvEKpwrYLOcz6k=.ee2955ca-8705-4ccf-8769-8c20b12dea57@github.com>

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

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

I agree with the patch. It is not GLIBC-tunable as it is not listed in [sysdeps/x86/cpu-tunables.c](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-tunables.c).

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

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

From tpushkin at openjdk.org  Thu Jan 29 09:00:10 2026
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 29 Jan 2026 09:00:10 GMT
Subject: [crac] RFR: Merge jdk:jdk-27+5 [v2]
In-Reply-To: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
References: <miUAkQVlDrmhj3ukYshO8zifrwxbD4rPKZjBGkm2jcA=.75911aa7-6df2-4a52-b01f-ccfd906dc305@github.com>
Message-ID: <6wQBUsoIdUc_2dfonDjhPUAOJctxAKhkYxg7imr915Q=.b9a66cba-7942-4506-a5a6-eea8b6efc7f7@github.com>

> 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
> 
> Currently two tests that use images from https://github.com/CRaC/container-images fail in CI because the glibc-based image needs to be updated (CI now uses glibc 2.38) ? I am working on that in that repo, no related changes in this repo are expected.

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

  Fixups

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

Changes:
  - all: https://git.openjdk.org/crac/pull/288/files
  - new: https://git.openjdk.org/crac/pull/288/files/f493f95e..de768936

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=288&range=00-01

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

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

From jkratochvil at openjdk.org  Fri Jan 30 20:20:17 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 30 Jan 2026 20:20:17 GMT
Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or
 missing CPU features, try using -XX:CPUFeatures=0xfoo,
 0xbar on checkpoint [v4]
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: <O_D7pZ5CUuG6p4BTTXYresWh3rkcKflwuRHBYcBHn1I=.d9e60dfd-a89c-4f50-8f50-8e3da6f1149e@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 seven additional commits since the last revision:

 - Merge branch 'crac' into crac-conjunction
 - Fixes upon review by Radim Vansa
 - 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/80b71be0..2823dd3c

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

  Stats: 4644 lines in 71 files changed: 2801 ins; 1684 del; 159 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  Sat Jan 31 12:39:04 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 31 Jan 2026 12:39:04 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: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <iYEaBqTsQXAg7OtUYWs-VKWXflnX583z4RPN6rZqIyQ=.15a812aa-6880-4d22-9381-5559f35dc4e9@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:

  get_failed_bitmap to return stored data

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

Changes:
  - all: https://git.openjdk.org/crac/pull/278/files
  - new: https://git.openjdk.org/crac/pull/278/files/2823dd3c..69b9686b

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

  Stats: 32 lines in 7 files changed: 8 ins; 7 del; 17 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  Sat Jan 31 12:39:07 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 31 Jan 2026 12:39:07 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: <neaANNtpRlxWkS26srBZHlR6YsR_dBvekzqHGZPdgsg=.7f94689d-9592-47de-8f0d-615ddf16a828@github.com>

On Wed, 7 Jan 2026 16:21:51 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/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`.

Addressed by: https://github.com/openjdk/crac/pull/278/changes/69b9686bfb41d29762e02f7e3caf74237e8f3e18

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

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

From jkratochvil at openjdk.org  Sat Jan 31 13:31:03 2026
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 31 Jan 2026 13:31:03 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: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
References: <tOiduquLuCrG5S9XVybIQl-3YCD1dH17q-waaV8uWQg=.5ff91f1a-c17d-4184-991f-0361e47c4635@github.com>
Message-ID: <35ponK6qS69i06LWVJZZWPCrJTnB7Mg0DUZSzGUdM1U=.6e64eb81-528f-43e0-9e13-a18bce3b0d8f@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:

  Fix non-x86 builds

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

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

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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