From tpushkin at openjdk.org  Fri Aug  1 14:18:34 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 1 Aug 2025 14:18:34 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
Message-ID: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>

Adds tests for `CRaCIgnoreRestoreIfUnavailable`.

The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

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

Commit messages:
 - Remove old comment
 - Fix years in license headers
 - Test CRaCIgnoreRestoreIfUnavailable

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

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

From tpushkin at openjdk.org  Fri Aug  1 14:29:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 1 Aug 2025 14:29:13 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
In-Reply-To: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
Message-ID: <hVfyUtbjtTZnENr4NTv78hCpnGdFdIeuWth4_0aRghc=.f2f7e6b2-9e26-41e1-aa12-29870536cb5f@github.com>

On Fri, 1 Aug 2025 14:11:53 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
> 
> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

test/jdk/jdk/crac/ignoreRestore/RestoreIfPossibleTest.java line 65:

> 63: 
> 64:         final var out = builder.startRestoreWithArgs(null, List.of(Main.class.getName(), "false")).outputAnalyzer();
> 65:         out.stdoutShouldNotContain(WARMUP_MSG).stdoutShouldContain(MAIN_MSG);

Currently `MAIN_MSG` will actually be printed twice: once from newly launched main (because we provided new arguments on restore) and once from the original main.

Such behavior is inconvenient, especially when `-jar <jar-path>` is used (because new args feature does not support this yet and fails). It will be fixed once we add something like `-XX:+CRaCExecuteNewMain` required to execute new args:
- By default `CRaCExecuteNewMain` is false and restore fails if new args are provided (unless `-XX:+CRaCIgnoreRestoreIfUnavailable` is provided, then they should be ignored for restore but used if restore fails for another reason)
- With `-XX:+CRaCExecuteNewMain` new args are mandatory

With `-XX:+CRaCIgnoreRestoreIfUnavailable -XX:+CRaCExecuteNewMain` the behavior will be as it is now with just `-XX:+CRaCIgnoreRestoreIfUnavailable`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2248123783

From tpushkin at openjdk.org  Fri Aug  1 18:50:03 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 1 Aug 2025 18:50:03 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
Message-ID: <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>

> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
> 
> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

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

  Fix EngineFailureTest on linux-x86

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

Changes:
  - all: https://git.openjdk.org/crac/pull/255/files
  - new: https://git.openjdk.org/crac/pull/255/files/ea1adaca..68605a54

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

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

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

From tpushkin at openjdk.org  Fri Aug  1 19:27:36 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 1 Aug 2025 19:27:36 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs
Message-ID: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>

Besides some wording and formatting of VM options:
- Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
- Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

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

Commit messages:
 - Improve docs of CRaC VM options

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

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

From tpushkin at openjdk.org  Sat Aug  2 13:06:12 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Sat, 2 Aug 2025 13:06:12 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <JJWdNtfAGNLdq6SnSlnTDbq4KVD4dXDHySsk86FPFLA=.573214b3-69d6-4376-8ef0-40fb05f27645@github.com>

On Fri, 1 Aug 2025 19:22:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

src/java.base/share/man/java.md line 1090:

> 1088: `-XX:CRaCMinPid=`*value*
> 1089: :   A desired minimal PID value for checkpointed process. Used by the launcher,
> 1090:     only on POSIX-like platforms.

BTW, I thought about removing `CRaCMinPid` from `globals.hpp` since it is not used by the VM at all but decided against it (too big of a change for a pretty general PR like this) and just documented that it is to be used by the launcher.

Since it is (or should be) possible to use JVM without the default launcher we could add a check in VM that the option is honored and at least warn if it is not.

We've had similar problems with Tomcat launching JVM directly and thus not honoring options implemented purely in the launcher (see ZULU-79238).

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2249244467

From tpushkin at openjdk.org  Sat Aug  2 13:19:53 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Sat, 2 Aug 2025 13:19:53 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

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

  Improve wording for CRaCMinPid

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

Changes:
  - all: https://git.openjdk.org/crac/pull/256/files
  - new: https://git.openjdk.org/crac/pull/256/files/569e77b1..58a1dbc8

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

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

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

From dcherepanov at openjdk.org  Mon Aug  4 11:27:22 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 4 Aug 2025 11:27:22 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static JDK
 build
Message-ID: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>

The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.

It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).

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

Commit messages:
 - static-jdk

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

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

From tpushkin at openjdk.org  Mon Aug  4 12:38:20 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 12:38:20 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
Message-ID: <iJs_1hAelsQdcpnM6IFev_nCMoL96VtJsbJ3oUD6NTk=.f643e984-9ba5-44f0-93f8-8c52537fa028@github.com>

On Mon, 4 Aug 2025 11:22:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.
> 
> It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).

LGTM overall, thanks, just one question

test/jdk/ProblemList-StaticJdk.txt line 27:

> 25: jdk/crac/java/lang/System/NanoTimeTest.java                                      8364624 generic-all
> 26: jdk/crac/java/net/InetAddress/ResolveTest.java                                   8364624 generic-all
> 27: jdk/crac/java/lang/System/TimedWaitingTest.java                                  8364624 generic-all

Could you please explain what is the problem with these? The tests themselves should not require X11.

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

Marked as reviewed by tpushkin (Committer).

PR Review: https://git.openjdk.org/crac/pull/257#pullrequestreview-3084004299
PR Review Comment: https://git.openjdk.org/crac/pull/257#discussion_r2251358095

From rvansa at openjdk.org  Mon Aug  4 13:53:23 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 13:53:23 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <JJWdNtfAGNLdq6SnSlnTDbq4KVD4dXDHySsk86FPFLA=.573214b3-69d6-4376-8ef0-40fb05f27645@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <JJWdNtfAGNLdq6SnSlnTDbq4KVD4dXDHySsk86FPFLA=.573214b3-69d6-4376-8ef0-40fb05f27645@github.com>
Message-ID: <_JlVbcmR499am9ynkHAcBQ0b7ruT6xbtYBPLQ4KuEKQ=.b934534f-d522-471b-85b1-866639b19f40@github.com>

On Sat, 2 Aug 2025 13:03:59 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve wording for CRaCMinPid
>
> src/java.base/share/man/java.md line 1090:
> 
>> 1088: `-XX:CRaCMinPid=`*value*
>> 1089: :   A desired minimal PID value for checkpointed process. Used by the launcher,
>> 1090:     only on POSIX-like platforms.
> 
> BTW, I thought about removing `CRaCMinPid` from `globals.hpp` since it is not used by the VM at all but decided against it (too big of a change for a pretty general PR like this) and just documented that it is to be used by the launcher.
> 
> Since it is (or should be) possible to use JVM without the default launcher we could add a check in VM that the option is honored and at least warn if it is not.
> 
> Internally we've had similar problems with Tomcat launching JVM directly and thus not honoring options implemented purely in the launcher.

I don't think we should remove; it should be normally listed with `-XX:PrintFlagsFinal` etc.

Regarding wording, I don't think that "launcher" is a term that we should use in user-facing documentation.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251565150

From tpushkin at openjdk.org  Mon Aug  4 13:56:14 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 13:56:14 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <_JlVbcmR499am9ynkHAcBQ0b7ruT6xbtYBPLQ4KuEKQ=.b934534f-d522-471b-85b1-866639b19f40@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <JJWdNtfAGNLdq6SnSlnTDbq4KVD4dXDHySsk86FPFLA=.573214b3-69d6-4376-8ef0-40fb05f27645@github.com>
 <_JlVbcmR499am9ynkHAcBQ0b7ruT6xbtYBPLQ4KuEKQ=.b934534f-d522-471b-85b1-866639b19f40@github.com>
Message-ID: <vtreJMI6Tftkh-K6vg1W2ibCBWgOntXimDpnfNlMP88=.7c10e70b-00e2-4617-8f72-4480a61c7a39@github.com>

On Mon, 4 Aug 2025 13:51:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/man/java.md line 1090:
>> 
>>> 1088: `-XX:CRaCMinPid=`*value*
>>> 1089: :   A desired minimal PID value for checkpointed process. Used by the launcher,
>>> 1090:     only on POSIX-like platforms.
>> 
>> BTW, I thought about removing `CRaCMinPid` from `globals.hpp` since it is not used by the VM at all but decided against it (too big of a change for a pretty general PR like this) and just documented that it is to be used by the launcher.
>> 
>> Since it is (or should be) possible to use JVM without the default launcher we could add a check in VM that the option is honored and at least warn if it is not.
>> 
>> Internally we've had similar problems with Tomcat launching JVM directly and thus not honoring options implemented purely in the launcher.
>
> I don't think we should remove; it should be normally listed with `-XX:PrintFlagsFinal` etc.
> 
> Regarding wording, I don't think that "launcher" is a term that we should use in user-facing documentation.

This term is used a lot in this file, e.g. "To launch a class declared in a source file, run the `java` launcher in
source-file mode"

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251572280

From dcherepanov at openjdk.org  Mon Aug  4 14:20:20 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 4 Aug 2025 14:20:20 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <iJs_1hAelsQdcpnM6IFev_nCMoL96VtJsbJ3oUD6NTk=.f643e984-9ba5-44f0-93f8-8c52537fa028@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
 <iJs_1hAelsQdcpnM6IFev_nCMoL96VtJsbJ3oUD6NTk=.f643e984-9ba5-44f0-93f8-8c52537fa028@github.com>
Message-ID: <fcGWxW0J6daMpainPcPfQKNBFKrjQEgv11-ivG2qYkc=.f6a46c53-66db-4313-ac14-ce152839721f@github.com>

On Mon, 4 Aug 2025 12:35:43 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.
>> 
>> It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).
>
> test/jdk/ProblemList-StaticJdk.txt line 27:
> 
>> 25: jdk/crac/java/lang/System/NanoTimeTest.java                                      8364624 generic-all
>> 26: jdk/crac/java/net/InetAddress/ResolveTest.java                                   8364624 generic-all
>> 27: jdk/crac/java/lang/System/TimedWaitingTest.java                                  8364624 generic-all
> 
> Could you please explain what is the problem with these? The tests themselves should not require X11.

The tests fail with following error

> /jdk/bin/java: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory 

It seems that `libawt_xawt.so` has the dependency on `libX11.so.6` and when it's statically linked, `java` executable has the dependency.

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

PR Review Comment: https://git.openjdk.org/crac/pull/257#discussion_r2251641358

From rvansa at openjdk.org  Mon Aug  4 14:40:16 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 14:40:16 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
Message-ID: <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>

On Sat, 2 Aug 2025 13:19:53 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Besides some wording and formatting of VM options:
>> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
>> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve wording for CRaCMinPid

src/hotspot/share/runtime/globals.hpp line 1962:

> 1960:                                                                             \
> 1961:   product(ccstr, CRaCCheckpointTo, nullptr, RESTORE_SETTABLE,               \
> 1962:           "Path to place the checkpoint image into")                        \

I think it is still important to state that the path leads to a directory.

src/hotspot/share/runtime/globals.hpp line 1965:

> 1963:                                                                             \
> 1964:   product(ccstr, CRaCRestoreFrom, nullptr, RESTORE_SETTABLE,                \
> 1965:           "Path to the image to restore from. If restore succeeds, the "    \

In case of CRIU it is not really replaced, the restored VM is a child process of launcher stub...

src/hotspot/share/runtime/globals.hpp line 1969:

> 1967:                                                                             \
> 1968:   product(uint, CRaCMinPid, 128,                                            \
> 1969:           "Mininal PID value for checkpointed process (Unix only)")         \

`Unix` -> `POSIX` (same as in java.md). Linux is not Unix.

src/hotspot/share/runtime/globals.hpp line 2006:

> 2004:           "use -Djdk.crac.resource-policies=...")                           \
> 2005:                                                                             \
> 2006:   product(bool, CRaCSkipCheckpoint, false, DIAGNOSTIC,                      \

Shouldn't we rather deprecate/obsolete the option altogether? Sounds like a predecessor to `simengine`, that is the preferred way. Looking into the implementation it seems that this will keep `jcmd` hanging if invoked from that, won't it?

src/hotspot/share/runtime/globals.hpp line 2017:

> 2015:                                                                             \
> 2016:   product(bool, CRaCTraceStartupTime, false, DIAGNOSTIC,                    \
> 2017:           "Trace restore startup time")                                     \

So "restore" or "startup"? :-) What about

> Print timestamp after successful restore by CRaC engine

In general, I think that this should be turned into unified logging configuration option. It's also weird that it is not restore-settable, you have to set that on checkpoint...

src/hotspot/share/runtime/globals.hpp line 2020:

> 2018:                                                                             \
> 2019:   product(bool, CRaCDoThrowCheckpointException, true, EXPERIMENTAL,         \
> 2020:           "Throw CheckpointException if non-checkpointable low-level "      \

I don't really see what's the purpose, and there's no test. Since it's experimental, can we obsolete it righ away?

src/java.base/share/man/java.md line 1086:

> 1084: 
> 1085: `-XX:CRaCRestoreFrom=`*directory*
> 1086: :   Restores an image created by `-XX:CRaCCheckpointTo`.

The "by" is a bit out of place, since the option does not immediately trigger creation of the image. How about
> Restores an image written on checkpoint into `-XX:CRaCCheckpointTo` 

?

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251614732
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251618398
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251621208
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251647598
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251672186
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251683432
PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2251698312

From tpushkin at openjdk.org  Mon Aug  4 15:04:19 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 15:04:19 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <fcGWxW0J6daMpainPcPfQKNBFKrjQEgv11-ivG2qYkc=.f6a46c53-66db-4313-ac14-ce152839721f@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
 <iJs_1hAelsQdcpnM6IFev_nCMoL96VtJsbJ3oUD6NTk=.f643e984-9ba5-44f0-93f8-8c52537fa028@github.com>
 <fcGWxW0J6daMpainPcPfQKNBFKrjQEgv11-ivG2qYkc=.f6a46c53-66db-4313-ac14-ce152839721f@github.com>
Message-ID: <XVSyazQMRIg2FGzdZSvLgYGwry5Mgd8vCEHu2uNY9-s=.eecaf4cb-f3cf-4c77-b8dc-ba44725cd2d4@github.com>

On Mon, 4 Aug 2025 14:17:22 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

>> test/jdk/ProblemList-StaticJdk.txt line 27:
>> 
>>> 25: jdk/crac/java/lang/System/NanoTimeTest.java                                      8364624 generic-all
>>> 26: jdk/crac/java/net/InetAddress/ResolveTest.java                                   8364624 generic-all
>>> 27: jdk/crac/java/lang/System/TimedWaitingTest.java                                  8364624 generic-all
>> 
>> Could you please explain what is the problem with these? The tests themselves should not require X11.
>
> The tests fail with following error
> 
>> /jdk/bin/java: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory 
> 
> It seems that `libawt_xawt.so` has the dependency on `libX11.so.6` and when it's statically linked, `java` executable has the dependency.

I wonder why none of the tests from the mainline failed since some of these tests use the default base image which others should also use. Maybe tests using Docker are not included into the tiers run in CI...

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

PR Review Comment: https://git.openjdk.org/crac/pull/257#discussion_r2251771024

From rvansa at openjdk.org  Mon Aug  4 15:21:23 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 15:21:23 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
Message-ID: <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>

On Fri, 1 Aug 2025 18:50:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
>> 
>> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix EngineFailureTest on linux-x86

test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 51:

> 49:         // Create an empty image which will pass VM's own checks. It may contain
> 50:         // CPU features, for example.
> 51:         new CracBuilder().engine(CracEngine.SIMULATE)

OK, this creates the empty directory (or rather one with just features), but what's the point? Just making the 'restore' below fail at a different point of time? If there are two ways of failure, both should be tested.

test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 55:

> 53:             .startCheckpoint().waitForSuccess();
> 54: 
> 55:         new CracBuilder()

The `crexec` option for `CRaCEngine` is weird; looks like a leftover from times when we had `CREngineLibrary` as well. Is it supposed to execute CRIU, or completely fail the restore, leading to 'unavailable'?

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2251814642
PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2251808490

From dcherepanov at openjdk.org  Mon Aug  4 15:40:07 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 4 Aug 2025 15:40:07 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
Message-ID: <L1k1r6lEjLp06EZbhkTVFdlE3YlQ0woYZcInRqdlZQs=.6a8aca95-8408-4d67-932f-1a091a798197@github.com>

On Mon, 4 Aug 2025 11:22:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.
> 
> It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).

Thanks for the review

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

PR Comment: https://git.openjdk.org/crac/pull/257#issuecomment-3151270185

From duke at openjdk.org  Mon Aug  4 15:40:07 2025
From: duke at openjdk.org (duke)
Date: Mon, 4 Aug 2025 15:40:07 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
Message-ID: <cD5KOMrFW9PU0l-bO3XPEcTYXWE5BjWbc1VR4_S1pwA=.3e4547c8-b611-4fa3-bbeb-654791eeafed@github.com>

On Mon, 4 Aug 2025 11:22:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.
> 
> It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).

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

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

PR Comment: https://git.openjdk.org/crac/pull/257#issuecomment-3151274532

From dcherepanov at openjdk.org  Mon Aug  4 15:40:07 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 4 Aug 2025 15:40:07 GMT
Subject: [crac] RFR: 8364624: [CRaC] Resolve startup failures with static
 JDK build
In-Reply-To: <XVSyazQMRIg2FGzdZSvLgYGwry5Mgd8vCEHu2uNY9-s=.eecaf4cb-f3cf-4c77-b8dc-ba44725cd2d4@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
 <iJs_1hAelsQdcpnM6IFev_nCMoL96VtJsbJ3oUD6NTk=.f643e984-9ba5-44f0-93f8-8c52537fa028@github.com>
 <fcGWxW0J6daMpainPcPfQKNBFKrjQEgv11-ivG2qYkc=.f6a46c53-66db-4313-ac14-ce152839721f@github.com>
 <XVSyazQMRIg2FGzdZSvLgYGwry5Mgd8vCEHu2uNY9-s=.eecaf4cb-f3cf-4c77-b8dc-ba44725cd2d4@github.com>
Message-ID: <LtuDtELjPOMEL2DykS4JM7A4TXQXvxkuR5ra_vD4bf8=.9a7f7245-1e7c-4e58-ab8f-54143c24fa5a@github.com>

On Mon, 4 Aug 2025 15:01:07 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> The tests fail with following error
>> 
>>> /jdk/bin/java: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory 
>> 
>> It seems that `libawt_xawt.so` has the dependency on `libX11.so.6` and when it's statically linked, `java` executable has the dependency.
>
> I wonder why none of the tests from the mainline failed since some of these tests use the default base image which others should also use. Maybe tests using Docker are not included into the tiers run in CI...

Yes, the tests using Docker from mainline aren't included in tiers that run in CI. I haven't checked this but if they had been running, they most likely would have failed with a similar error.

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

PR Review Comment: https://git.openjdk.org/crac/pull/257#discussion_r2251855473

From dcherepanov at openjdk.org  Mon Aug  4 16:23:08 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 4 Aug 2025 16:23:08 GMT
Subject: [crac] Integrated: 8364624: [CRaC] Resolve startup failures with
 static JDK build
In-Reply-To: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
References: <bTePZOxgc8wVuo8Ms-VnMT4pWJD66cItauK3w7dRY-U=.ec590b9d-567b-4769-848c-81cf7ad88f13@github.com>
Message-ID: <KjOm7BBNvd3UrNrj7hwdS3F0QU5TbC8eXGvHwD8NKf4=.50c67162-de3f-4d59-bf0f-43d638c5930f@github.com>

On Mon, 4 Aug 2025 11:22:37 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The patch fixes locating the `lib` folder and also fixes handling for `crexec` case for static JDK build.
> 
> It also fixes "setup CRIU" test step and ensures that criu is copied into static JDK for static JDK build. Another change in tests is to re-enable tests for static JDK and add some CRaC tests with known failures to the exclude list for static JDK (tests requiring jcmd and tests requiring a container with libX11 preinstalled).

This pull request has now been integrated.

Changeset: 137fba64
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
Committer: Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/137fba643e720d28e2446640ae5f9f3e9e491251
Stats:     46 lines in 4 files changed: 30 ins; 0 del; 16 mod

8364624: [CRaC] Resolve startup failures with static JDK build

Reviewed-by: tpushkin

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

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

From tpushkin at openjdk.org  Mon Aug  4 18:40:28 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 18:40:28 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser
Message-ID: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>

Options for restore are now processed during the common VM arguments parsing stage.

Notable improvements compared to the old code:
- Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
- Option aliasing is now handled correctly

**Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.

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

Commit messages:
 - Integrate restore arg parsing into the main arg parsing code

Changes: https://git.openjdk.org/crac/pull/258/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364662
  Stats: 311 lines in 7 files changed: 194 ins; 100 del; 17 mod
  Patch: https://git.openjdk.org/crac/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/258/head:pull/258

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

From duke at openjdk.org  Mon Aug  4 18:42:10 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:42:10 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
Message-ID: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>

#### Summary

This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.

#### Problem

When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:

1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.

This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:


$ jcmd 3403046 JDK.checkpoint
3403046:
...
JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
...
An exception during a checkpoint operation:
jdk.internal.crac.mirror.CheckpointException
    Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
        at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
        ...
    Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
        at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
        ...
        at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
        ...
    Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
        at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
        ...


#### Solution

The fundamental assumption behind this solution is that JARs provided via `--patch-module` should be treated as persistent resources, just like those on the classpath. It is expected that these files will be available at the same location after a restore.

This PR implements a two-pronged approach to address both file handles:

1.  **Java-level Fix**: The `jdk.internal.module.ModulePatcher$JarResourceFinder` is modified to use `jdk.internal.util.jar.PersistentJarFile` instead of the standard `java.util.jar.JarFile`. This ensures that the file handle opened by the Java module system is registered as a CRaC `JDKResource`, making it a managed and permissible resource during checkpointing.

2.  **Native-level Fix**: To handle the file descriptor opened by the native `ClassLoader`, we introduce a new mechanism to whitelist it:
    *   A new function, `ClassLoader::get_patch_module_entry_fds()`, is added in `classLoader.cpp`. This function iterates through the `_patch_mod_entries` and collects the file descriptors of all associated JAR files.
    *   In `crac_linux.cpp`, the `VM_Crac::check_fds` function now calls this new method to retrieve the list of patch-module file descriptors. These FDs are then added to the allowlist, and `check_fds` will correctly identify them as `OK: claimed by patch-module`, thus avoiding the exception.

By implementing these changes, we ensure that both file descriptors associated with a patched module's JAR are correctly recognized as persistent and valid, allowing the checkpoint to proceed successfully.

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

Commit messages:
 - style: Add final newline to PatchModuleTest.java
 - Apply review suggestions from TimPushkin
 - test(crac): add PatchModuleTest for --patch-module compatibility
 - include patch module fds in CRaC check

Changes: https://git.openjdk.org/crac/pull/241/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=241&range=00
  Stats: 168 lines in 5 files changed: 167 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/crac/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/241/head:pull/241

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

From rvansa at openjdk.org  Mon Aug  4 18:42:10 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 18:42:10 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
Message-ID: <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>

On Thu, 10 Jul 2025 03:11:03 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
> 
> #### Problem
> 
> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
> 
> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
> 
> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
> 
> 
> $ jcmd 3403046 JDK.checkpoint
> 3403046:
> ...
> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
> ...
> An exception during a checkpoint operation:
> jdk.internal.crac.mirror.CheckpointException
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>         ...
>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>         ...
>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>         ...
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>         ...
> 
> 
> #### Solution
> 
> The fundamental assumption behind this solution is that JARs provided via `--patch-module` ...

Thank you for the contribution! The change looks good in general, could you add a JTReg test that demonstrates that this is working as expected, and make sure that the CI runs it?

Great work, let's just sort out the OCA and enable running the testsuite in your repo.

Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).

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

PR Review: https://git.openjdk.org/crac/pull/241#pullrequestreview-3016754271
Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/241#pullrequestreview-3032569774

From tpushkin at openjdk.org  Mon Aug  4 18:42:12 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 18:42:12 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
Message-ID: <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>

On Thu, 10 Jul 2025 03:11:03 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
> 
> #### Problem
> 
> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
> 
> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
> 
> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
> 
> 
> $ jcmd 3403046 JDK.checkpoint
> 3403046:
> ...
> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
> ...
> An exception during a checkpoint operation:
> jdk.internal.crac.mirror.CheckpointException
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>         ...
>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>         ...
>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>         ...
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>         ...
> 
> 
> #### Solution
> 
> The fundamental assumption behind this solution is that JARs provided via `--patch-module` ...

Small comments from me, nothing functionally important

src/hotspot/share/classfile/classLoader.cpp line 763:

> 761:   GrowableArray<int> fds;
> 762:   assert(Thread::current()->is_VM_thread(), "should be called from VM op");
> 763:   if (_patch_mod_entries == NULL) {

Suggestion:

  if (_patch_mod_entries == nullptr) {

src/hotspot/share/classfile/classLoader.cpp line 766:

> 764:     return fds;
> 765:   }
> 766:   // we don't use mutexes here because it is called from VM op

As I see it, all patch module entries are opened once at VM initialization (in `ClassLoader::setup_patch_mod_entries()`) and checkpoint cannot be called before then. If that is so, there should be no VM thread / mutex requirements to read it.

test/jdk/jdk/crac/fileDescriptors/PatchModuleTest.java line 140:

> 138:         return (String) patcherClass.getMethod("getInfo").invoke(null);
> 139:     }
> 140: }

I haven't looked through the test but if you will be applying Radim's suggestions please also add a newline at the end of file

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

PR Review: https://git.openjdk.org/crac/pull/241#pullrequestreview-3023357209
PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2209395175
PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2209442941
PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2215534987

From duke at openjdk.org  Mon Aug  4 18:42:12 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:42:12 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
Message-ID: <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>

On Mon, 14 Jul 2025 15:12:33 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Thank you for the contribution! The change looks good in general, could you add a JTReg test that demonstrates that this is working as expected, and make sure that the CI runs it?

Thank you for the feedback! I've added a new JTReg test,  `crac/fileDescriptors/PatchModuleTest.java`.

The test is designed to cover all aspects of the fix:

1.  **Simulates a Real-World Patch**: It dynamically compiles a new class and packages it into a JAR. This JAR is then used with `--patch-module` to add the new class to the `java.base` module at runtime. 

2.  **Verifies Patch Functionality**: The test confirms that the class loaded from the patched module works as expected both before the checkpoint and after the restore.

3. **Ensures Checkpoint/Restore Succeeds**: A key part of the test is to ensure that the entire checkpoint and restore process completes successfully without throwing a CheckpointException. This directly confirms that the original bug (unhandled file descriptors causing checkpoint failure) is resolved.

 4.  **Validates Both Fixes**: The test analyzes the output of the checkpointing process to explicitly verify both parts of the solution.

> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
> 
> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).

Hi @rvansa ,

Thanks for the review and the green light on the changes! 

That's a great point about using simengine for broader platform compatibility. My reasoning for choosing the criu engine was specifically to test a true physical restore. A goal here is to verify that the module patch remains effective after the process's native state has been completely dumped and then reloaded by CRIU.

Since you mentioned it's okay to keep it, I'd prefer to stick with criu for this test to ensure that comprehensive validation.

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3086581158
PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3095049250

From rvansa at openjdk.org  Mon Aug  4 18:42:12 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 18:42:12 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>
Message-ID: <sCXss2-fwjIeQGletvRHfkU6nsVZZo4S8MqkIq6B89o=.292571cf-cf34-484e-8572-4db618ff0cba@github.com>

On Wed, 16 Jul 2025 07:06:29 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> #### Summary
>> 
>> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
>> 
>> #### Problem
>> 
>> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
>> 
>> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
>> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
>> 
>> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
>> 
>> 
>> $ jcmd 3403046 JDK.checkpoint
>> 3403046:
>> ...
>> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
>> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
>> ...
>> An exception during a checkpoint operation:
>> jdk.internal.crac.mirror.CheckpointException
>>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>>         ...
>>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>>         ...
>>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>>         ...
>>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>>         ...
>> 
>> 
>> #### Solution
>> 
>> The fundamental...
>
> Small comments from me, nothing functionally important

@TimPushkin I wonder if we should make `simengine` the default in `CracBuilder`; that way we can encourage everyone to test everywhere and use CRIU only when the test is really specific to any of its behaviour (which it shouldn't be for the most part - everything `Resource`-related is applicable to all engines).

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3088514822

From tpushkin at openjdk.org  Mon Aug  4 18:42:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 4 Aug 2025 18:42:13 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <sCXss2-fwjIeQGletvRHfkU6nsVZZo4S8MqkIq6B89o=.292571cf-cf34-484e-8572-4db618ff0cba@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>
 <sCXss2-fwjIeQGletvRHfkU6nsVZZo4S8MqkIq6B89o=.292571cf-cf34-484e-8572-4db618ff0cba@github.com>
Message-ID: <kNv2Gl0SInj3nonpqSpdj_RKOOooW6_G9v5EDGwlxUs=.f8b81846-8441-4a99-9f44-d0e0352cf874@github.com>

On Fri, 18 Jul 2025 08:37:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Small comments from me, nothing functionally important
>
> @TimPushkin I wonder if we should make `simengine` the default in `CracBuilder`; that way we can encourage everyone to test everywhere and use CRIU only when the test is really specific to any of its behaviour (which it shouldn't be for the most part - everything `Resource`-related is applicable to all engines).

@rvansa Yes, I agree

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3088710080

From duke at openjdk.org  Mon Aug  4 18:42:13 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:42:13 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
 <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>
Message-ID: <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>

On Mon, 21 Jul 2025 02:22:39 GMT, mazhen <duke at openjdk.org> wrote:

> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
> 
> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).

Hi @rvansa , 

a quick follow-up on the OCA status. I've been waiting for approval for over a month and it seems to be stalled.  Would you have any advice or be able to help nudge the process internally? Any help would be a huge boost. Thanks!

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3101669741

From rvansa at openjdk.org  Mon Aug  4 18:42:14 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 4 Aug 2025 18:42:14 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
 <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>
 <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>
Message-ID: <NysFcsfMOiW71UgD9_LxAQP_vR7t2M9wwaNz5cdMtzw=.c61594b7-0916-470d-886f-94d167bc1a73@github.com>

On Tue, 22 Jul 2025 08:37:48 GMT, mazhen <duke at openjdk.org> wrote:

>>> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
>>> 
>>> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).
>> 
>> Hi @rvansa ,
>> 
>> Thanks for the review and the green light on the changes! 
>> 
>> That's a great point about using simengine for broader platform compatibility. My reasoning for choosing the criu engine was specifically to test a true physical restore. A goal here is to verify that the module patch remains effective after the process's native state has been completely dumped and then reloaded by CRIU.
>> 
>> Since you mentioned it's okay to keep it, I'd prefer to stick with criu for this test to ensure that comprehensive validation.
>
>> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
>> 
>> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).
> 
> Hi @rvansa , 
> 
> a quick follow-up on the OCA status. I've been waiting for approval for over a month and it seems to be stalled.  Would you have any advice or be able to help nudge the process internally? Any help would be a huge boost. Thanks!

@mz1999 OCA is handled by Oracle, so we don't really have such internal connection. When I was requesting the approval it also took a while and I had to ping `opensource_ww_grp at oracle.com` asking them to check on the request. Are you requesting individual OCA or with company? In the latter case they request official approval that you can contribute to OSS.

@mz1999 Hi, any luck getting a response from Oracle?

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3104599922
PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3129914781

From duke at openjdk.org  Mon Aug  4 18:42:14 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:42:14 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
 <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>
 <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>
Message-ID: <loxSYsmGLLW3UPpWPaK86007aaHWaX_giPliVZRxcq0=.d3438e1d-a14f-4ee9-9e6b-db680c0d8d34@github.com>

On Tue, 22 Jul 2025 08:37:48 GMT, mazhen <duke at openjdk.org> wrote:

>>> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
>>> 
>>> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).
>> 
>> Hi @rvansa ,
>> 
>> Thanks for the review and the green light on the changes! 
>> 
>> That's a great point about using simengine for broader platform compatibility. My reasoning for choosing the criu engine was specifically to test a true physical restore. A goal here is to verify that the module patch remains effective after the process's native state has been completely dumped and then reloaded by CRIU.
>> 
>> Since you mentioned it's okay to keep it, I'd prefer to stick with criu for this test to ensure that comprehensive validation.
>
>> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
>> 
>> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).
> 
> Hi @rvansa , 
> 
> a quick follow-up on the OCA status. I've been waiting for approval for over a month and it seems to be stalled.  Would you have any advice or be able to help nudge the process internally? Any help would be a huge boost. Thanks!

> @mz1999 Hi, any luck getting a response from Oracle?

Hi @rvansa ,

I am applying for an Individual OCA. I suspected there might have been an issue with the original submission, so I withdrew it and submitted a fresh Individual Agreement last week (on July 22nd).

It's currently 'under review', and I'm hopeful this one will be processed smoothly. I'll post an update here as soon as it's approved.

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3130317571

From duke at openjdk.org  Mon Aug  4 18:42:15 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:42:15 GMT
Subject: [crac] RFR: [CRaC] Support checkpointing with --patch-module by
 treating patch JARs as persistent
In-Reply-To: <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <1gx56ltLfpBscC3KIG85eXwNtH_C4GrsWkSHfm1aahE=.76dbe22c-9494-454f-843f-e105b9f454b0@github.com>
Message-ID: <-qG-CXUPURgTkg_J2IZ7oDm6A5kpqzgueu9bMMwwWbo=.6d7e1bfd-cb6b-494a-a66f-3b0453fba516@github.com>

On Wed, 16 Jul 2025 06:31:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> #### Summary
>> 
>> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
>> 
>> #### Problem
>> 
>> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
>> 
>> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
>> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
>> 
>> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
>> 
>> 
>> $ jcmd 3403046 JDK.checkpoint
>> 3403046:
>> ...
>> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
>> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
>> ...
>> An exception during a checkpoint operation:
>> jdk.internal.crac.mirror.CheckpointException
>>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>>         ...
>>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>>         ...
>>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>>         ...
>>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>>         ...
>> 
>> 
>> #### Solution
>> 
>> The fundamental...
>
> src/hotspot/share/classfile/classLoader.cpp line 763:
> 
>> 761:   GrowableArray<int> fds;
>> 762:   assert(Thread::current()->is_VM_thread(), "should be called from VM op");
>> 763:   if (_patch_mod_entries == NULL) {
> 
> Suggestion:
> 
>   if (_patch_mod_entries == nullptr) {

Thanks! Good catch. Using nullptr is definitely better practice. I'll make the change.

> src/hotspot/share/classfile/classLoader.cpp line 766:
> 
>> 764:     return fds;
>> 765:   }
>> 766:   // we don't use mutexes here because it is called from VM op
> 
> As I see it, all patch module entries are opened once at VM initialization (in `ClassLoader::setup_patch_mod_entries()`) and checkpoint cannot be called before then. If that is so, there should be no VM thread / mutex requirements to read it.

That's a great point. Your analysis of the `_patch_mod_entries` lifecycle makes perfect sense. Since it's effectively read-only after initialization, the VM thread assertion isn't necessary. I'll remove it and the related comment. Thanks for spotting this!

> test/jdk/jdk/crac/fileDescriptors/PatchModuleTest.java line 140:
> 
>> 138:         return (String) patcherClass.getMethod("getInfo").invoke(null);
>> 139:     }
>> 140: }
> 
> I haven't looked through the test but if you will be applying Radim's suggestions please also add a newline at the end of file

Good catch, thanks! I've pushed a commit with the added newline.

I've also left a comment on Radim's suggestion explaining why I'm sticking with the criu engine for this test to ensure a full physical restore is validated.

Appreciate the review!

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

PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2215129538
PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2215132619
PR Review Comment: https://git.openjdk.org/crac/pull/241#discussion_r2218096036

From tpushkin at openjdk.org  Tue Aug  5 06:50:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 06:50:32 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
Message-ID: <zJTo1hC0HTYHsapWYY9WwkoHG3oY_zlfBXwquzlEi1M=.ac7e94f9-a17d-4a5e-9a80-146a02920654@github.com>

On Mon, 4 Aug 2025 15:18:05 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix EngineFailureTest on linux-x86
>
> test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 51:
> 
>> 49:         // Create an empty image which will pass VM's own checks. It may contain
>> 50:         // CPU features, for example.
>> 51:         new CracBuilder().engine(CracEngine.SIMULATE)
> 
> OK, this creates the empty directory (or rather one with just features), but what's the point? Just making the 'restore' below fail at a different point of time? If there are two ways of failure, both should be tested.

Yes, if there are no CPU features ? that is a different failure.

Did not want to add a test for that because I am not testing CPU features in this PR, but this particular one should not be hard to implement so I'll add it.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2253318275

From tpushkin at openjdk.org  Tue Aug  5 06:57:21 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 06:57:21 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
Message-ID: <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>

On Mon, 4 Aug 2025 15:16:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix EngineFailureTest on linux-x86
>
> test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 55:
> 
>> 53:             .startCheckpoint().waitForSuccess();
>> 54: 
>> 55:         new CracBuilder()
> 
> The `crexec` option for `CRaCEngine` is weird; looks like a leftover from times when we had `CREngineLibrary` as well. Is it supposed to execute CRIU, or completely fail the restore, leading to 'unavailable'?

There is a long comment above explaining why this is done like this. Basically we need the failure to happen before `exec`ing the engine executable because there is no return to the parent VM from there.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2253333276

From tpushkin at openjdk.org  Tue Aug  5 07:03:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 07:03:17 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>
Message-ID: <5q89UbUyVFij-Wq80GOpDMefEmiCsFkHwbCL6rfjlzk=.cdef085d-7adb-4017-a94b-e343bd479648@github.com>

On Tue, 5 Aug 2025 06:55:02 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 55:
>> 
>>> 53:             .startCheckpoint().waitForSuccess();
>>> 54: 
>>> 55:         new CracBuilder()
>> 
>> The `crexec` option for `CRaCEngine` is weird; looks like a leftover from times when we had `CREngineLibrary` as well. Is it supposed to execute CRIU, or completely fail the restore, leading to 'unavailable'?
>
> There is a long comment above explaining why this is done like this. Basically we need the failure to happen before `exec`ing the engine executable because there is no return to the parent VM from there.

If we had some library-based engine besides `crexec` I would use that

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2253343800

From tpushkin at openjdk.org  Tue Aug  5 07:17:18 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 07:17:18 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v3]
In-Reply-To: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
Message-ID: <o8psFGYLGOPUZDPBwOfGYzIcXzTISeOyhu5iqKeKE3A=.f6f824e4-1e03-451f-a083-f446f47d51a1@github.com>

> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
> 
> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

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

  Test missing CPU features file

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

Changes:
  - all: https://git.openjdk.org/crac/pull/255/files
  - new: https://git.openjdk.org/crac/pull/255/files/68605a54..7ef6c30e

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

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

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

From tpushkin at openjdk.org  Tue Aug  5 07:17:19 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 07:17:19 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <zJTo1hC0HTYHsapWYY9WwkoHG3oY_zlfBXwquzlEi1M=.ac7e94f9-a17d-4a5e-9a80-146a02920654@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <zJTo1hC0HTYHsapWYY9WwkoHG3oY_zlfBXwquzlEi1M=.ac7e94f9-a17d-4a5e-9a80-146a02920654@github.com>
Message-ID: <BGlQ5M-hIJrr2S9D3M6oQ6gc8j3hwQZaUh68VCOEIDc=.a428ffdd-ec1f-4db9-9cb6-6b727c981c59@github.com>

On Tue, 5 Aug 2025 06:48:00 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> test/jdk/jdk/crac/ignoreRestore/EngineFailureTest.java line 51:
>> 
>>> 49:         // Create an empty image which will pass VM's own checks. It may contain
>>> 50:         // CPU features, for example.
>>> 51:         new CracBuilder().engine(CracEngine.SIMULATE)
>> 
>> OK, this creates the empty directory (or rather one with just features), but what's the point? Just making the 'restore' below fail at a different point of time? If there are two ways of failure, both should be tested.
>
> Yes, if there are no CPU features ? that is a different failure.
> 
> Did not want to add a test for that because I am not testing CPU features in this PR, but this particular one should not be hard to implement so I'll add it.

Added  `NoCPUFeaturesTest`

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2253364580

From tpushkin at openjdk.org  Tue Aug  5 07:39:30 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 07:39:30 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
 <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
Message-ID: <tV0-a5FfgyUQaFaIJstIq8YIrtrHFhcUwLBblbOA4zg=.91529a75-780a-49fb-a9ca-7069d36925d6@github.com>

On Mon, 4 Aug 2025 14:10:30 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve wording for CRaCMinPid
>
> src/hotspot/share/runtime/globals.hpp line 1969:
> 
>> 1967:                                                                             \
>> 1968:   product(uint, CRaCMinPid, 128,                                            \
>> 1969:           "Mininal PID value for checkpointed process (Unix only)")         \
> 
> `Unix` -> `POSIX` (same as in java.md). Linux is not Unix.

I agree but I am following the style of the file. In this file "(Unix only)" is used for 3 other options while "posix" is not used at all.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2253423260

From tpushkin at openjdk.org  Tue Aug  5 07:56:46 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 07:56:46 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
 <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
Message-ID: <ZHgkMvm2HAg2Prcu5_Iv0JLtsz840u1MVPaI7rdDuis=.66e5b6e4-4ee4-41a4-9d49-c20a00e1be16@github.com>

On Mon, 4 Aug 2025 14:19:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve wording for CRaCMinPid
>
> src/hotspot/share/runtime/globals.hpp line 2006:
> 
>> 2004:           "use -Djdk.crac.resource-policies=...")                           \
>> 2005:                                                                             \
>> 2006:   product(bool, CRaCSkipCheckpoint, false, DIAGNOSTIC,                      \
> 
> Shouldn't we rather deprecate/obsolete the option altogether? Sounds like a predecessor to `simengine`, that is the preferred way. Looking into the implementation it seems that this will keep `jcmd` hanging if invoked from that, won't it?

I used it recently when doing performance investigations: it allowed to rule out influence of the engine on checkpoint/restore performance. So it still can be useful. But I agree, some tests wouldn't harm.

> it seems that this will keep jcmd hanging if invoked from that, won't it?

No, the connection is closed after the JCMD operation is finished, as for any other JCMD operation. `report_ok_to_jcmd_if_any` is needed when we use an engine to close the socket before checkpointing.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2253467617

From tpushkin at openjdk.org  Tue Aug  5 08:30:34 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 08:30:34 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v2]
In-Reply-To: <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
 <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
Message-ID: <Ol6lyJgbdzRehcSE_TiTyw6tApbgw1w7uQ4ihFeLEp8=.5bbedcea-a8bb-47e8-93ff-e5f91b010a64@github.com>

On Mon, 4 Aug 2025 14:27:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve wording for CRaCMinPid
>
> src/hotspot/share/runtime/globals.hpp line 2017:
> 
>> 2015:                                                                             \
>> 2016:   product(bool, CRaCTraceStartupTime, false, DIAGNOSTIC,                    \
>> 2017:           "Trace restore startup time")                                     \
> 
> So "restore" or "startup"? :-) What about
> 
>> Print timestamp after successful restore by CRaC engine
> 
> In general, I think that this should be turned into unified logging configuration option. It's also weird that it is not restore-settable, you have to set that on checkpoint...

Will improve the wording. The name can also be improved but I'll leave it as is for now since maybe the option should be deprecated (see below).

> It's also weird that it is not restore-settable, you have to set that on checkpoint

We cannot really make it restore-settable because the timestamp is printed before restore-settable options are read. Unless we record the timestamp to print it later.

We also have `jdk.crac.trace-startup-time` property used for the same purpose on the Java side (also cannot be changed on restore, although it could be) ? we should probably unify these deprecating one of them. If they get unified the VM-level one should continue without the unified logging so that it prints to the same destination as the Java-level one.

Anyway, I'll open a separate task for this as there are thinks to be thought through.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2253541100

From tpushkin at openjdk.org  Tue Aug  5 09:24:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 09:24:17 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v3]
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <0vSNQTVeBeCCfm2cO04tUo_hMGF1pND9EL91MSloluk=.e17fc3ea-ebf0-49fa-83b9-1422e4d32f14@github.com>

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

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

  Apply review suggestions

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

Changes:
  - all: https://git.openjdk.org/crac/pull/256/files
  - new: https://git.openjdk.org/crac/pull/256/files/58a1dbc8..4b7e1911

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

  Stats: 20 lines in 5 files changed: 4 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/crac/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/256/head:pull/256

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

From tpushkin at openjdk.org  Tue Aug  5 09:44:35 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 09:44:35 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

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

  Fix CRaCSkipCheckpoint aliasing

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

Changes:
  - all: https://git.openjdk.org/crac/pull/256/files
  - new: https://git.openjdk.org/crac/pull/256/files/4b7e1911..e661cdf3

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

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

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

From tpushkin at openjdk.org  Tue Aug  5 09:51:18 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 09:51:18 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
Message-ID: <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>

On Tue, 5 Aug 2025 09:44:35 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Besides some wording and formatting of VM options:
>> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
>> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix CRaCSkipCheckpoint aliasing

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

> 1: /*

BTW maybe it is time to put expiration dates for all of CRaC's deprecated/obsoleted options? Almost all of them are aliases and having aliases slows down argument parsing: for each parsed argument there is a linear search through the list of aliases to try to find the real name.

Since most of them have been deprecated since winter we can put 26 as the expiration version: it will be more a year since the options were deprecated. For the ones deprecated/obsoleted today it can be 27.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2253780936

From tpushkin at openjdk.org  Tue Aug  5 10:07:46 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 10:07:46 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v4]
In-Reply-To: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
Message-ID: <Kz6rsrPHsLtz98snDngAYODCgdfH3livm9OamXEdkGE=.da3d4a48-5063-4918-b517-63f09f0f543d@github.com>

> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
> 
> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

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

  Run NoCPUFeaturesTest only on Linux

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

Changes:
  - all: https://git.openjdk.org/crac/pull/255/files
  - new: https://git.openjdk.org/crac/pull/255/files/7ef6c30e..e93f742c

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

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

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

From rvansa at openjdk.org  Tue Aug  5 12:37:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 5 Aug 2025 12:37:31 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <5q89UbUyVFij-Wq80GOpDMefEmiCsFkHwbCL6rfjlzk=.cdef085d-7adb-4017-a94b-e343bd479648@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>
 <5q89UbUyVFij-Wq80GOpDMefEmiCsFkHwbCL6rfjlzk=.cdef085d-7adb-4017-a94b-e343bd479648@github.com>
Message-ID: <zV0-ATqaetcAqazKyFhm4XQaTQouFkuUvjFy0Nj0_ps=.9327b2ae-09ac-4832-9b1a-b17fdb65005f@github.com>

On Tue, 5 Aug 2025 07:00:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> There is a long comment above explaining why this is done like this. Basically we need the failure to happen before `exec`ing the engine executable because there is no return to the parent VM from there.
>
> If we had some library-based engine besides `crexec` I would use that

Could we use `-XX:CRaCEngineOptions=fail-with=unknown-option` instead? Or even `-XX:CRaCEngine=non-existent`?

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2254210688

From rvansa at openjdk.org  Tue Aug  5 12:46:19 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 5 Aug 2025 12:46:19 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <BGlQ5M-hIJrr2S9D3M6oQ6gc8j3hwQZaUh68VCOEIDc=.a428ffdd-ec1f-4db9-9cb6-6b727c981c59@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <zJTo1hC0HTYHsapWYY9WwkoHG3oY_zlfBXwquzlEi1M=.ac7e94f9-a17d-4a5e-9a80-146a02920654@github.com>
 <BGlQ5M-hIJrr2S9D3M6oQ6gc8j3hwQZaUh68VCOEIDc=.a428ffdd-ec1f-4db9-9cb6-6b727c981c59@github.com>
Message-ID: <9k6actnP_QUK4NV6ur31O4gcjhxML14rTKuJIZZDcJs=.1785a212-726b-41c8-a6d9-58bdf8c05c7d@github.com>

On Tue, 5 Aug 2025 07:09:45 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Yes, if there are no CPU features ? that is a different failure.
>> 
>> Did not want to add a test for that because I am not testing CPU features in this PR, but this particular one should not be hard to implement so I'll add it.
>
> Added  `NoCPUFeaturesTest`

I was not implying that you should add the test for missing CPU features, but good to have one.

My point is that running `simengine` alone should be a no-op (yes, you're testing that simengine works, but that's not a point of this test). The comment says `Create an empty image` but simengine is not supposed to create an empty image, it is not supposed to do anything. As a side-effect, JVM creates the directory.

My understanding is that you are doing that to prevent checks before entering the engine to fail in a different manner than the test is supposed to do. I consider running the test with two different engines a confusing, obscure way to get the prerequisites; you could just `mkdir` and write a dummy CPU features file.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2254234508

From tpushkin at openjdk.org  Tue Aug  5 13:10:36 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 13:10:36 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <zV0-ATqaetcAqazKyFhm4XQaTQouFkuUvjFy0Nj0_ps=.9327b2ae-09ac-4832-9b1a-b17fdb65005f@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>
 <5q89UbUyVFij-Wq80GOpDMefEmiCsFkHwbCL6rfjlzk=.cdef085d-7adb-4017-a94b-e343bd479648@github.com>
 <zV0-ATqaetcAqazKyFhm4XQaTQouFkuUvjFy0Nj0_ps=.9327b2ae-09ac-4832-9b1a-b17fdb65005f@github.com>
Message-ID: <w8WUDpvqE2G9dLTYwmDDVTYuTUoRL2ClUntX-gpn-_M=.d9375717-3754-4ceb-ab1f-c1c0ccd1b9d7@github.com>

On Tue, 5 Aug 2025 12:34:17 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> If we had some library-based engine besides `crexec` I would use that
>
> Could we use `-XX:CRaCEngineOptions=fail-with=unknown-option` instead? Or even `-XX:CRaCEngine=non-existent`?

No, these are both VM-side failures, I could add tests for those but they are all currently handled in the same way w.r.t. `CRaCIgnoreRestoreIfUnavailable` so I don't see a point.

This test is supposed to check a failure that is detected inside the `CRaCEngine::restore()` call, inside the engine library, and makes the call return.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2254289745

From tpushkin at openjdk.org  Tue Aug  5 13:18:25 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 5 Aug 2025 13:18:25 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <9k6actnP_QUK4NV6ur31O4gcjhxML14rTKuJIZZDcJs=.1785a212-726b-41c8-a6d9-58bdf8c05c7d@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <zJTo1hC0HTYHsapWYY9WwkoHG3oY_zlfBXwquzlEi1M=.ac7e94f9-a17d-4a5e-9a80-146a02920654@github.com>
 <BGlQ5M-hIJrr2S9D3M6oQ6gc8j3hwQZaUh68VCOEIDc=.a428ffdd-ec1f-4db9-9cb6-6b727c981c59@github.com>
 <9k6actnP_QUK4NV6ur31O4gcjhxML14rTKuJIZZDcJs=.1785a212-726b-41c8-a6d9-58bdf8c05c7d@github.com>
Message-ID: <7ORLXUSdxLxwwWZlBrfOIMZULAbA5KUSEghSPD6xWRg=.601481e7-0b63-450b-b605-977f412160f2@github.com>

On Tue, 5 Aug 2025 12:44:11 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Added  `NoCPUFeaturesTest`
>
> I was not implying that you should add the test for missing CPU features, but good to have one.
> 
> My point is that running `simengine` alone should be a no-op (yes, you're testing that simengine works, but that's not a point of this test). The comment says `Create an empty image` but simengine is not supposed to create an empty image, it is not supposed to do anything. As a side-effect, JVM creates the directory.
> 
> My understanding is that you are doing that to prevent checks before entering the engine to fail in a different manner than the test is supposed to do. I consider running the test with two different engines a confusing, obscure way to get the prerequisites; you could just `mkdir` and write a dummy CPU features file.

Writing a dummy CPU features file would make the test depend on the format of the file, i.e. both on crexec and CPU features implementation.

The only way I see to make the test less artificial is to create a library-based simengine.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2254312962

From tpushkin at openjdk.org  Wed Aug  6 15:39:15 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 6 Aug 2025 15:39:15 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests
Message-ID: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>

Stabilizes recompiler tests:
- `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
- In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.

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

Commit messages:
 - Update error message
 - Make recompiler tests more stable

Changes: https://git.openjdk.org/crac/pull/259/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364931
  Stats: 104 lines in 2 files changed: 67 ins; 16 del; 21 mod
  Patch: https://git.openjdk.org/crac/pull/259.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/259/head:pull/259

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

From rvansa at openjdk.org  Wed Aug  6 15:42:27 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 6 Aug 2025 15:42:27 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v2]
In-Reply-To: <w8WUDpvqE2G9dLTYwmDDVTYuTUoRL2ClUntX-gpn-_M=.d9375717-3754-4ceb-ab1f-c1c0ccd1b9d7@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <46L7bWDZ_O07E5a7Jp5YlvJQ9tVO7etDIaPET3P9Zgs=.cda06e51-259f-4b3d-ab31-602a68a68459@github.com>
 <zwqiQHXiqUAXkDYpXFN0setnRHaXMvtL6IggASXAp-k=.8697d010-cdf4-453f-a871-235bbdecbed0@github.com>
 <-Rheq7E6IX5raRaqUX0VKwZ0B5M239do5EyAUcytZjw=.4e748191-2062-4f67-bb28-ed4ed7ec0ea2@github.com>
 <5q89UbUyVFij-Wq80GOpDMefEmiCsFkHwbCL6rfjlzk=.cdef085d-7adb-4017-a94b-e343bd479648@github.com>
 <zV0-ATqaetcAqazKyFhm4XQaTQouFkuUvjFy0Nj0_ps=.9327b2ae-09ac-4832-9b1a-b17fdb65005f@github.com>
 <w8WUDpvqE2G9dLTYwmDDVTYuTUoRL2ClUntX-gpn-_M=.d9375717-3754-4ceb-ab1f-c1c0ccd1b9d7@github.com>
Message-ID: <fqoYoanoBNC9yDhYjKmQ2V4uUjPdHQwVAlrmDRedQPg=.8b4a867c-292f-45f2-b959-375a1b0c6b56@github.com>

On Tue, 5 Aug 2025 13:06:21 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Could we use `-XX:CRaCEngineOptions=fail-with=unknown-option` instead? Or even `-XX:CRaCEngine=non-existent`?
>
> No, these are both VM-side failures, I could add tests for those but they are all currently handled in the same way w.r.t. `CRaCIgnoreRestoreIfUnavailable` so I don't see a point.
> 
> This test is supposed to check a failure that is detected inside the `CRaCEngine::restore()` call, inside the engine library, and makes the call return.

OK, if you're saying there's no better way let's keep it as is.

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

PR Review Comment: https://git.openjdk.org/crac/pull/255#discussion_r2257590850

From rvansa at openjdk.org  Wed Aug  6 15:52:32 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 6 Aug 2025 15:52:32 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v4]
In-Reply-To: <Kz6rsrPHsLtz98snDngAYODCgdfH3livm9OamXEdkGE=.da3d4a48-5063-4918-b517-63f09f0f543d@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <Kz6rsrPHsLtz98snDngAYODCgdfH3livm9OamXEdkGE=.da3d4a48-5063-4918-b517-63f09f0f543d@github.com>
Message-ID: <LJiIWGWl2glRkOHcq1Eg1sTJRFqhnMVNApEseF5sQpU=.704fad34-1485-41f6-abd5-0fcf06be22f8@github.com>

On Tue, 5 Aug 2025 10:07:46 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
>> 
>> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run NoCPUFeaturesTest only on Linux

I am not particularly happy about the way the test look like but since you've explored alternative options, let's live with that.

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/255#pullrequestreview-3093268000

From rvansa at openjdk.org  Wed Aug  6 15:57:30 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 6 Aug 2025 15:57:30 GMT
Subject: [crac] RFR: 8364737: [CRaC] Support checkpointing with
 --patch-module by treating patch JARs as persistent
In-Reply-To: <loxSYsmGLLW3UPpWPaK86007aaHWaX_giPliVZRxcq0=.d3438e1d-a14f-4ee9-9e6b-db680c0d8d34@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
 <lJebNbq-T-IVcVGUNi04Qu2TNM0888ALDJX4XZNUYb8=.195d9e9a-d990-4c29-ac76-b732619117ef@github.com>
 <-N0I27irrJllxd9Wr0JdB6QA7uLbLt_EAbwTlDo118I=.a4163b52-e6fa-45a9-8145-4ef9fe12ac4a@github.com>
 <Hq6Q5llqX0GUPDfGUDCEpp3_187xN5w6uQFrDUAqyzo=.ef48cc4e-1014-4f32-b86e-31fcb9366074@github.com>
 <loxSYsmGLLW3UPpWPaK86007aaHWaX_giPliVZRxcq0=.d3438e1d-a14f-4ee9-9e6b-db680c0d8d34@github.com>
Message-ID: <8qe66JqCDi42oPXqXO6xOgKZPjAQV9G7Qkts1FsP33E=.7455eafb-c9e2-4f2f-82cc-9ab2110393dc@github.com>

On Tue, 29 Jul 2025 02:03:27 GMT, mazhen <duke at openjdk.org> wrote:

>>> Great work, let's just sort out the OCA and enable running the testsuite in your repo.
>>> 
>>> Btw. the test could work using just `simengine` (there's nothing engine-specific and that would let us run on other platforms than only Linux) but it's OK to keep this on a real engine (CRIU).
>> 
>> Hi @rvansa , 
>> 
>> a quick follow-up on the OCA status. I've been waiting for approval for over a month and it seems to be stalled.  Would you have any advice or be able to help nudge the process internally? Any help would be a huge boost. Thanks!
>
>> @mz1999 Hi, any luck getting a response from Oracle?
> 
> Hi @rvansa ,
> 
> I am applying for an Individual OCA. I suspected there might have been an issue with the original submission, so I withdrew it and submitted a fresh Individual Agreement last week (on July 22nd).
> 
> It's currently 'under review', and I'm hopeful this one will be processed smoothly. I'll post an update here as soon as it's approved.

@mz1999 It seems that your OCA has landed, please type `/integrate` and I'll sponsor this.

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3160724644

From duke at openjdk.org  Wed Aug  6 17:47:46 2025
From: duke at openjdk.org (duke)
Date: Wed, 6 Aug 2025 17:47:46 GMT
Subject: [crac] RFR: 8364737: [CRaC] Support checkpointing with
 --patch-module by treating patch JARs as persistent
In-Reply-To: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
Message-ID: <uFB_L8nTjVY7pasLLRAc-f4ChJbzQcCZXgjal3AaEDA=.d29dedeb-2eba-4c03-a1c2-c9eaf5ce0523@github.com>

On Thu, 10 Jul 2025 03:11:03 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
> 
> #### Problem
> 
> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
> 
> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
> 
> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
> 
> 
> $ jcmd 3403046 JDK.checkpoint
> 3403046:
> ...
> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
> ...
> An exception during a checkpoint operation:
> jdk.internal.crac.mirror.CheckpointException
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>         ...
>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>         ...
>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>         ...
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>         ...
> 
> 
> #### Solution
> 
> The fundamental assumption behind this solution is that JARs provided via `--patch-module` ...

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

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

PR Comment: https://git.openjdk.org/crac/pull/241#issuecomment-3161035710

From tpushkin at openjdk.org  Thu Aug  7 06:22:36 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 06:22:36 GMT
Subject: [crac] RFR: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
 [v4]
In-Reply-To: <Kz6rsrPHsLtz98snDngAYODCgdfH3livm9OamXEdkGE=.da3d4a48-5063-4918-b517-63f09f0f543d@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
 <Kz6rsrPHsLtz98snDngAYODCgdfH3livm9OamXEdkGE=.da3d4a48-5063-4918-b517-63f09f0f543d@github.com>
Message-ID: <CjTWWL0z2aIjbBQ7zmZryuECc4SeTcGwyWrDQiZy76Q=.9d3b7bae-fe9f-4d36-8c7b-24ce10306ef6@github.com>

On Tue, 5 Aug 2025 10:07:46 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
>> 
>> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run NoCPUFeaturesTest only on Linux

Thank you for the review.

I believe it is only `EngineFailureTest.java` you don't like but yes, I don't see ways to improve it until we add a library-based engine to OpenJDK.

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

PR Comment: https://git.openjdk.org/crac/pull/255#issuecomment-3162662694

From tpushkin at openjdk.org  Thu Aug  7 06:25:31 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 06:25:31 GMT
Subject: [crac] Integrated: 8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable
In-Reply-To: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
References: <0YGsgkdpPJq7dDkRoE6ADGh3dCBfeGcRtVt5-p6ZIK8=.0afedc9b-a3ff-420b-bcdc-633efd3c69d5@github.com>
Message-ID: <cfwwfJGaJhS7OStAm5Dxz0gkzzY0oYWTvS_k7OtLdXI=.56903d23-ed0a-4ba4-86ff-2e3ca78bafe3@github.com>

On Fri, 1 Aug 2025 14:11:53 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds tests for `CRaCIgnoreRestoreIfUnavailable`.
> 
> The case for incompatible CPU features is not tested, although I believe it should work. Such test would be more complex (to the best of my knowledge, emulation is needed to be able to reduce the set of available features between checkpoint and restore) so it deserves a separate task. It would be something like what `test/jdk/jdk/crac/CPUFeatures/CPUFeatures.sh` does (have never run it, not sure if it works).

This pull request has now been integrated.

Changeset: 10f1db5d
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/10f1db5d41fdc5c8d4c11048144c2d1164733810
Stats:     361 lines in 6 files changed: 356 ins; 0 del; 5 mod

8364538: [CRaC] Test CRaCIgnoreRestoreIfUnavailable

Reviewed-by: rvansa

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

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

From duke at openjdk.org  Thu Aug  7 06:29:48 2025
From: duke at openjdk.org (mazhen)
Date: Thu, 7 Aug 2025 06:29:48 GMT
Subject: [crac] Integrated: 8364737: [CRaC] Support checkpointing with
 --patch-module by treating patch JARs as persistent
In-Reply-To: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
References: <Kz2C0DKosXjVnnfXAsZHns0yopeVQXixQ3ou-H-nTZY=.657bef06-e239-4e17-9f0c-4217f5082c70@github.com>
Message-ID: <H8II4WKps75qN-YaahvwKEcuyrC2RzkFma_XDzojvSA=.32375031-500e-46ea-bdfc-d8d9a32c7f3a@github.com>

On Thu, 10 Jul 2025 03:11:03 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This change enhances CRaC's checkpointing capabilities to correctly handle applications launched with the `--patch-module` option. Previously, using a JAR file with `--patch-module` would cause checkpointing to fail due to unmanaged file descriptors. This patch resolves the issue by treating these JARs as persistent resources, similar to how classpath JARs are handled.
> 
> #### Problem
> 
> When a JAR file is specified via `--patch-module`, it is opened by two distinct mechanisms within the JVM:
> 
> 1.  **Native `ClassLoader`**: The C++ `ClassLoader` implementation opens the JAR file to build its internal class path structures. This results in a file descriptor that is not managed by CRaC's Java-level resource tracking, leading to it being flagged as a "BAD: opened by application" file during `check_fds`.
> 2.  **Java `ModulePatcher`**: The Java-level `jdk.internal.module.ModulePatcher` also opens the same JAR to scan for packages and resources. While this could be made CRaC-aware, the native-level file descriptor remains an issue.
> 
> This dual-opening mechanism leads to `CheckpointOpenFileException` being thrown for both file descriptors during a checkpoint, preventing a successful image creation. The log output clearly illustrates this problem:
> 
> 
> $ jcmd 3403046 JDK.checkpoint
> 3403046:
> ...
> JVM: FD fd=4 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" BAD: opened by application
> JVM: FD fd=5 type=regular path="/home/mazhen/works/patch-demo/legacy-patch.jar" OK: claimed by java code
> ...
> An exception during a checkpoint operation:
> jdk.internal.crac.mirror.CheckpointException
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: legacy-patch.jar
>         at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$0(JDKFileResource.java:90)
>         ...
>     Caused by: java.lang.Exception: This file descriptor was created by main at epoch:1752027938791 here
>         at java.base/jdk.internal.crac.JDKFdResource.<init>(JDKFdResource.java:40)
>         ...
>         at java.base/jdk.internal.module.ModulePatcher$JarResourceFinder.<init>(ModulePatcher.java:433)
>         ...
>     Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=4 type=regular path=/home/mazhen/works/patch-demo/legacy-patch.jar
>         at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:115)
>         ...
> 
> 
> #### Solution
> 
> The fundamental assumption behind this solution is that JARs provided via `--patch-module` ...

This pull request has now been integrated.

Changeset: 329cbcc7
Author:    mazhen <mz1999 at gmail.com>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/329cbcc7318a15db6e7d2ec62b7cc379c8dd9f54
Stats:     168 lines in 5 files changed: 167 ins; 0 del; 1 mod

8364737: [CRaC] Support checkpointing with --patch-module by treating patch JARs as persistent

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Thu Aug  7 06:59:40 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 7 Aug 2025 06:59:40 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
Message-ID: <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>

On Thu, 31 Jul 2025 16:41:20 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> New main is now launched after restoration completes solving the issues outlined in the JBS task.
>> 
>> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
>> 
>> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
>> Exception in thread "main" jdk.crac.RestoreException
>>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>>                 at Main.main(Main.java:4)
>>         Caused by: java.lang.ClassNotFoundException: app.jar
>>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>                 at java.base/java.lang.Class.forName0(Native Method)
>>                 at java.base/java.lang.Class.forName(Class.java:547)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>>                 ... 3 more
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing space

Looks good, just a few minor remarks to code structure.

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

> 224:         restoreException.throwIfAny();
> 225: 
> 226:         final var parsedNewArguments = new ArrayList<String>();

`checkpointRestore1` is already a bit long; could you extract this to another method, please?

test/jdk/jdk/crac/newArgs/CheckpointInNewMainTest.java line 59:

> 57:         final var out = builder.doRestore().outputAnalyzer();
> 58: 
> 59:         out.shouldContain(RESTORE_OLD_MSG).shouldContain(RESTORE_NEW_MSG);

I think that a common pattern is to suppress continuation of the old main. Could you call add a variant that calls `System.exit(0)` in `InternalMain` and assert that `RESTORE_OLD_MSG` is not printed in that case?

test/jdk/jdk/crac/newArgs/FailedCheckpointRestoreTest.java line 52:

> 50: 
> 51:     public enum Variant {
> 52:         SUCCESS,

The `SUCCESS` variant looks identical to `CheckpointInNewMainTest`, except for registering a resource that wouldn't do anything. Could you merge these?

test/jdk/jdk/crac/newArgs/FailedCheckpointRestoreTest.java line 104:

> 102:             System.out.println(RESTORE_MSG);
> 103:         } catch (CheckpointException ex) {
> 104:             if (variant != Variant.CHECKPOINT_EXCEPTION) {

Could you rather check this using `jdk.test.lib.Asserts.*`?

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

PR Review: https://git.openjdk.org/crac/pull/253#pullrequestreview-3095585516
PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259271706
PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259254663
PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259267289
PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259263108

From tpushkin at openjdk.org  Thu Aug  7 08:03:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:03:32 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
 <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
Message-ID: <QXTEClNghVF1aJuMlL8F5razRvXitdAiMrwDTOxTtqM=.e4ada778-2901-4055-880b-6f3c17c26daa@github.com>

On Thu, 7 Aug 2025 06:52:16 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing space
>
> test/jdk/jdk/crac/newArgs/FailedCheckpointRestoreTest.java line 104:
> 
>> 102:             System.out.println(RESTORE_MSG);
>> 103:         } catch (CheckpointException ex) {
>> 104:             if (variant != Variant.CHECKPOINT_EXCEPTION) {
> 
> Could you rather check this using `jdk.test.lib.Asserts.*`?

With asserts I'd need to format the the caught exception by myself to print it. Just using `ex.toString()` will not include all the info `throw` includes.

The current way:

Exception in thread "main" java.lang.IllegalStateException: Unexpected suppression message
        at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:126)
        at jdk.test.lib.crac.CracTest.run(CracTest.java:165)
        at jdk.test.lib.crac.CracTest.main(CracTest.java:90)
Caused by: jdk.crac.RestoreException
        Suppressed: java.lang.RuntimeException: restoreFail
                at FailedCheckpointRestoreTest$1.afterRestore(FailedCheckpointRestoreTest.java:99)
                at jdk.crac/jdk.crac.ResourceWrapper.afterRestore(ResourceWrapper.java:78)
                at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeAfterRestore(AbstractContext.java:49)
                at java.base/jdk.internal.crac.mirror.impl.AbstractContext.afterRestore(AbstractContext.java:74)
                at jdk.crac/jdk.crac.ContextWrapper.afterRestore(ContextWrapper.java:61)
                at jdk.crac/jdk.crac.ResourceWrapper.afterRestore(ResourceWrapper.java:78)
                at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeAfterRestore(AbstractContext.java:49)
                at java.base/jdk.internal.crac.mirror.impl.AbstractContext.afterRestore(AbstractContext.java:74)
                at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:205)
                at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:287)
                at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
                at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
                at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:106)
                at jdk.test.lib.crac.CracTest.run(CracTest.java:165)
                at jdk.test.lib.crac.CracTest.main(CracTest.java:90)


Using `Asserts.assertEquals(restoreFail, ex.getSuppressed()[0].getMessage(), "Unexpected suppression message: " + ex)`:

Exception in thread "main" java.lang.RuntimeException: Unexpected suppression message: jdk.crac.RestoreException expected: Failing on restore! but was: restoreFail
        at jdk.test.lib.Asserts.fail(Asserts.java:715)
        at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
        at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:127)
        at jdk.test.lib.crac.CracTest.run(CracTest.java:165)
        at jdk.test.lib.crac.CracTest.main(CracTest.java:90)


Sure it can be formatted better but just using `throw` seems easier.

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

PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259470679

From rvansa at openjdk.org  Thu Aug  7 08:13:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 7 Aug 2025 08:13:38 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser
In-Reply-To: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
Message-ID: <Sw0m_ONB6faiAXfiTzeJrC3Nm4mwUFqf7E62iBktDSw=.9d16556c-c129-4a22-90eb-e19e3e45bcb0@github.com>

On Mon, 4 Aug 2025 18:12:57 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Options for restore are now processed during the common VM arguments parsing stage.
> 
> Notable improvements compared to the old code:
> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
> - Option aliasing is now handled correctly
> 
> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.

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

> 1044: }
> 1045: 
> 1046: void Arguments::build_jvm_restore_flags(const char* arg) {

I would use `append_jvm_restore_flags` - `build` implies the final operation on a builder.

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

> 2968:     // Restored JVM will search for the flag using the name we record here so we
> 2969:     // must ensure the real one is recorded
> 2970:     if (strncmp(name, flag->name(), name_len) == 0) {

If `name` is a prefix of `flag->name()` this will pass - check `name_len == strlen(flag->name())` first

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

> 2973:       const size_t real_tail_len = strlen(arg) + (strlen(flag->name()) - name_len);
> 2974:       char* const real_tail = AllocateHeap(real_tail_len + 1, MemTag::mtArguments);
> 2975:       const int ret = jio_snprintf(real_tail, real_tail_len + 1, "%s%s", flag->name(), arg + name_len);

Where are `+BoolOpt` flags handled?

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

> 636:         // should be concatenated. But with the current code the last occurence
> 637:         // will just overwrite the previous ones.
> 638:         assert(!JVMFlag::find_flag(cursor)->ccstr_accumulates(),

Ouch! I think that using multiple `-XX:CRaCEngineOptions` would be pretty common (at least some of my scripts do that). Could we fix this?

And this error should be guarantee/another check that is applied in release build, too because it verifies user input, not some invariants in internal components.

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

PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259472908
PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259483064
PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259480715
PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259340658

From tpushkin at openjdk.org  Thu Aug  7 08:37:04 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:37:04 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v3]
In-Reply-To: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
Message-ID: <ZlJKORw8_wZpDaNd9CSiEwZKGfLdogmCWit5b2snF_g=.24a6ba0f-94af-4f43-9dad-1e48f2fab0b2@github.com>

> New main is now launched after restoration completes solving the issues outlined in the JBS task.
> 
> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
> 
> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
> Exception in thread "main" jdk.crac.RestoreException
>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>                 at Main.main(Main.java:4)
>         Caused by: java.lang.ClassNotFoundException: app.jar
>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>                 at java.base/java.lang.Class.forName0(Native Method)
>                 at java.base/java.lang.Class.forName(Class.java:547)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>                 ... 3 more

Timofei Pushkin has updated the pull request incrementally with three additional commits since the last revision:

 - Move new args parsing into a separate method
 - Test exiting from new main
 - Extend waitForCheckpointed logging

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

Changes:
  - all: https://git.openjdk.org/crac/pull/253/files
  - new: https://git.openjdk.org/crac/pull/253/files/fe256b05..551757c4

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

  Stats: 88 lines in 4 files changed: 45 ins; 23 del; 20 mod
  Patch: https://git.openjdk.org/crac/pull/253.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/253/head:pull/253

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

From tpushkin at openjdk.org  Thu Aug  7 08:37:05 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:37:05 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
 <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
Message-ID: <jJ6VL7zVT2HXQ5P-9W_3bJL19S0-RdIZLZPiQQEAIs8=.512808ea-5999-4047-88ad-939729fa1690@github.com>

On Thu, 7 Aug 2025 06:48:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing space
>
> test/jdk/jdk/crac/newArgs/CheckpointInNewMainTest.java line 59:
> 
>> 57:         final var out = builder.doRestore().outputAnalyzer();
>> 58: 
>> 59:         out.shouldContain(RESTORE_OLD_MSG).shouldContain(RESTORE_NEW_MSG);
> 
> I think that a common pattern is to suppress continuation of the old main. Could you call add a variant that calls `System.exit(0)` in `InternalMain` and assert that `RESTORE_OLD_MSG` is not printed in that case?

Added this to `FailedCheckpointRestoreTest` ? felt a bit more appropriate since it tests various points at which execution ends. Although the clearest way would be to add a separate test...

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

PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259543430

From tpushkin at openjdk.org  Thu Aug  7 08:37:05 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:37:05 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <jJ6VL7zVT2HXQ5P-9W_3bJL19S0-RdIZLZPiQQEAIs8=.512808ea-5999-4047-88ad-939729fa1690@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
 <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
 <jJ6VL7zVT2HXQ5P-9W_3bJL19S0-RdIZLZPiQQEAIs8=.512808ea-5999-4047-88ad-939729fa1690@github.com>
Message-ID: <PZWH9y73-ZQWuyWdgbRCLXTj7DCIp3EW2Be6ojPEOg4=.d3e522e6-93c8-4c82-b05e-f0dbb6ac0f45@github.com>

On Thu, 7 Aug 2025 08:29:06 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> test/jdk/jdk/crac/newArgs/CheckpointInNewMainTest.java line 59:
>> 
>>> 57:         final var out = builder.doRestore().outputAnalyzer();
>>> 58: 
>>> 59:         out.shouldContain(RESTORE_OLD_MSG).shouldContain(RESTORE_NEW_MSG);
>> 
>> I think that a common pattern is to suppress continuation of the old main. Could you call add a variant that calls `System.exit(0)` in `InternalMain` and assert that `RESTORE_OLD_MSG` is not printed in that case?
>
> Added this to `FailedCheckpointRestoreTest` ? felt a bit more appropriate since it tests various points at which execution ends. Although the clearest way would be to add a separate test...

I better add a separate test indeed

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

PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259558997

From tpushkin at openjdk.org  Thu Aug  7 08:53:16 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:53:16 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v4]
In-Reply-To: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
Message-ID: <_96JBK47ahYwIFxlOSLdmhcaIGbs-N4JcK9ZpU1rlZI=.38eff984-a51f-4b6b-9b34-2cd35e80ebfb@github.com>

> New main is now launched after restoration completes solving the issues outlined in the JBS task.
> 
> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
> 
> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
> Exception in thread "main" jdk.crac.RestoreException
>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>                 at Main.main(Main.java:4)
>         Caused by: java.lang.ClassNotFoundException: app.jar
>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>                 at java.base/java.lang.Class.forName0(Native Method)
>                 at java.base/java.lang.Class.forName(Class.java:547)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>                 ... 3 more

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

  Test exiting from new main in a separate test

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

Changes:
  - all: https://git.openjdk.org/crac/pull/253/files
  - new: https://git.openjdk.org/crac/pull/253/files/551757c4..fb5295f7

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

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

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

From tpushkin at openjdk.org  Thu Aug  7 08:57:29 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 08:57:29 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
 <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
Message-ID: <QeTOWABdLnLpGbq5wHhQEElyRQc0ljUUfSSlyPVAnCw=.9e67b122-087e-46e9-b1da-a49e638fecf0@github.com>

On Thu, 7 Aug 2025 06:54:02 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing space
>
> test/jdk/jdk/crac/newArgs/FailedCheckpointRestoreTest.java line 52:
> 
>> 50: 
>> 51:     public enum Variant {
>> 52:         SUCCESS,
> 
> The `SUCCESS` variant looks identical to `CheckpointInNewMainTest`, except for registering a resource that wouldn't do anything. Could you merge these?

Removed this but it basically got moved to `ExitFromNewMainTest` with false as an argument. I just think that even though `CheckpointInNewMainTest` currently does test this its purpose is different (to test calling checkpoint in the new main) so it may eventually change and stop testing this (e.g. we may add `System.exit()` to it for some reason).

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

PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2259612291

From tpushkin at openjdk.org  Thu Aug  7 09:02:37 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 09:02:37 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser
In-Reply-To: <Sw0m_ONB6faiAXfiTzeJrC3Nm4mwUFqf7E62iBktDSw=.9d16556c-c129-4a22-90eb-e19e3e45bcb0@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
 <Sw0m_ONB6faiAXfiTzeJrC3Nm4mwUFqf7E62iBktDSw=.9d16556c-c129-4a22-90eb-e19e3e45bcb0@github.com>
Message-ID: <uuZ1mSa6JspNpdXPZsFBSm9xwKeZKUqW5oXppbd3Sxw=.51f5612e-2e88-4b9a-b2db-ea31f8220900@github.com>

On Thu, 7 Aug 2025 08:01:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Options for restore are now processed during the common VM arguments parsing stage.
>> 
>> Notable improvements compared to the old code:
>> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
>> - Option aliasing is now handled correctly
>> 
>> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.
>
> src/hotspot/share/runtime/arguments.cpp line 1046:
> 
>> 1044: }
>> 1045: 
>> 1046: void Arguments::build_jvm_restore_flags(const char* arg) {
> 
> I would use `append_jvm_restore_flags` - `build` implies the final operation on a builder.

I follow the style of the class: there are `Arguments::build_jvm_args` and `Arguments::build_jvm_flags` which do exactly the same thing, just for two different arrays.

> src/hotspot/share/runtime/crac.cpp line 638:
> 
>> 636:         // should be concatenated. But with the current code the last occurence
>> 637:         // will just overwrite the previous ones.
>> 638:         assert(!JVMFlag::find_flag(cursor)->ccstr_accumulates(),
> 
> Ouch! I think that using multiple `-XX:CRaCEngineOptions` would be pretty common (at least some of my scripts do that). Could we fix this?
> 
> And this error should be guarantee/another check that is applied in release build, too because it verifies user input, not some invariants in internal components.

This is not an issue for `CRaCEngineOptions` because it is not applied in the restored process (you can see it is handled in another branch above).

Currently there are no `ccstrlist` restore-settables actually being applied in the restored process, that is why I just added this assert for now. Its purpose is to fail when we add such option.

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

PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259626820
PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259620693

From tpushkin at openjdk.org  Thu Aug  7 09:34:39 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 09:34:39 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser
In-Reply-To: <Sw0m_ONB6faiAXfiTzeJrC3Nm4mwUFqf7E62iBktDSw=.9d16556c-c129-4a22-90eb-e19e3e45bcb0@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
 <Sw0m_ONB6faiAXfiTzeJrC3Nm4mwUFqf7E62iBktDSw=.9d16556c-c129-4a22-90eb-e19e3e45bcb0@github.com>
Message-ID: <911uxfBwfGmlHHOs69PaN8_nuHSmiQwhTupviZBrOdI=.2a0d60f0-b345-4799-8969-eddff32dce39@github.com>

On Thu, 7 Aug 2025 08:05:07 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Options for restore are now processed during the common VM arguments parsing stage.
>> 
>> Notable improvements compared to the old code:
>> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
>> - Option aliasing is now handled correctly
>> 
>> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.
>
> src/hotspot/share/runtime/arguments.cpp line 2975:
> 
>> 2973:       const size_t real_tail_len = strlen(arg) + (strlen(flag->name()) - name_len);
>> 2974:       char* const real_tail = AllocateHeap(real_tail_len + 1, MemTag::mtArguments);
>> 2975:       const int ret = jio_snprintf(real_tail, real_tail_len + 1, "%s%s", flag->name(), arg + name_len);
> 
> Where are `+BoolOpt` flags handled?

Oh, actually there are no aliased restore-settable boolean options so they don't reach this branch and are not handled. But this is not intentional, I just forgot about them and there are no tests since such things don't exist... I should fix this anyway, thanks for pointing out.

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

PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2259706553

From tpushkin at openjdk.org  Thu Aug  7 10:09:34 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 7 Aug 2025 10:09:34 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser [v2]
In-Reply-To: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
Message-ID: <M_4tDy-kW30qll_RCADRy0K3rfprlhudosTYe7NxMMg=.470861cd-882f-4b09-82f6-e964c2675edb@github.com>

> Options for restore are now processed during the common VM arguments parsing stage.
> 
> Notable improvements compared to the old code:
> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
> - Option aliasing is now handled correctly
> 
> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Fix flag name comparison
 - Handle aliased restore-settable boolean options

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

Changes:
  - all: https://git.openjdk.org/crac/pull/258/files
  - new: https://git.openjdk.org/crac/pull/258/files/c59efa51..3a1080b3

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

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

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

From rvansa at openjdk.org  Fri Aug  8 10:41:35 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 10:41:35 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v2]
In-Reply-To: <QXTEClNghVF1aJuMlL8F5razRvXitdAiMrwDTOxTtqM=.e4ada778-2901-4055-880b-6f3c17c26daa@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <TFLIFKAhUq9Tla9aNuRhxubTmZLD2zcUVgZqMOPdfTk=.f7313e18-66aa-4967-aa9f-d5f70b13f948@github.com>
 <sq4hYNe9xeKvqxbtOQ3FvC2LJ9wnWqOH5PDuc7-0jN8=.bcdcf03b-a9c1-47e7-8e38-0fa8072045fa@github.com>
 <QXTEClNghVF1aJuMlL8F5razRvXitdAiMrwDTOxTtqM=.e4ada778-2901-4055-880b-6f3c17c26daa@github.com>
Message-ID: <2qbUNeORtYEHyPC6MF1soTm2nsEGmW1QeeN0AVhvbmw=.ebfd4d04-adb2-4bf2-88d7-5e5df17fdb60@github.com>

On Thu, 7 Aug 2025 08:00:50 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> test/jdk/jdk/crac/newArgs/FailedCheckpointRestoreTest.java line 104:
>> 
>>> 102:             System.out.println(RESTORE_MSG);
>>> 103:         } catch (CheckpointException ex) {
>>> 104:             if (variant != Variant.CHECKPOINT_EXCEPTION) {
>> 
>> Could you rather check this using `jdk.test.lib.Asserts.*`?
>
> With asserts I'd need to format the the caught exception by myself to print it. Just using `ex.toString()` will not include all the info `throw` includes.
> 
> The current way:
> 
> Exception in thread "main" java.lang.IllegalStateException: Unexpected suppression message
>         at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:126)
>         at jdk.test.lib.crac.CracTest.run(CracTest.java:165)
>         at jdk.test.lib.crac.CracTest.main(CracTest.java:90)
> Caused by: jdk.crac.RestoreException
>         Suppressed: java.lang.RuntimeException: restoreFail
>                 at FailedCheckpointRestoreTest$1.afterRestore(FailedCheckpointRestoreTest.java:99)
>                 at jdk.crac/jdk.crac.ResourceWrapper.afterRestore(ResourceWrapper.java:78)
>                 at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeAfterRestore(AbstractContext.java:49)
>                 at java.base/jdk.internal.crac.mirror.impl.AbstractContext.afterRestore(AbstractContext.java:74)
>                 at jdk.crac/jdk.crac.ContextWrapper.afterRestore(ContextWrapper.java:61)
>                 at jdk.crac/jdk.crac.ResourceWrapper.afterRestore(ResourceWrapper.java:78)
>                 at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeAfterRestore(AbstractContext.java:49)
>                 at java.base/jdk.internal.crac.mirror.impl.AbstractContext.afterRestore(AbstractContext.java:74)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:205)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:287)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>                 at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:106)
>                 at jdk.test.lib.crac.CracTest.run(CracTest.java:165)
>                 at jdk.test.lib.crac.CracTest.main(CracTest.java:90)
> 
> 
> Using `Asserts.assertEquals(restoreFail, ex.getSuppressed()[0].getMessage(), "Unexpected suppression message: " + ex)`:
> 
> Exception in thread "main" java.lang.RuntimeException: Unexpected suppression message: jdk.crac.RestoreException expected: Failing on restore! but was: restoreFail
>         at jdk.test.lib.Asserts.fail(Asserts.java:715)
>         at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
>         at FailedCheckpointRestoreTest.exec(FailedCheckpointRestoreTest.java:127)
>         at jdk.test.lib.crac.CracT...

I haven't noticed the exception. I suppose if the asserts don't let you propagate the exception, you could add that variant:

    /* Current method */
    public static void assertEquals(Object lhs, Object rhs, String msg) {
        if ((lhs != rhs) && ((lhs == null) || !(lhs.equals(rhs)))) {
            fail((msg == null ? "assertEquals" : msg) + " expected: " + lhs + " but was: " + rhs);
        }
    }
    
    /* Replace with this */
    public static void assertEquals(Object lhs, Object rhs, String msg) {
        assertEquals(lhs, rhs, msg, null);
    }

    public static void assertEquals(Object lhs, Object rhs, String msg, Throwable cause) {
        if ((lhs != rhs) && ((lhs == null) || !(lhs.equals(rhs)))) {
            fail((msg == null ? "assertEquals" : msg) + " expected: " + lhs + " but was: " + rhs, cause);
        }
    }

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

PR Review Comment: https://git.openjdk.org/crac/pull/253#discussion_r2262593653

From rvansa at openjdk.org  Fri Aug  8 10:56:39 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 10:56:39 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser [v2]
In-Reply-To: <M_4tDy-kW30qll_RCADRy0K3rfprlhudosTYe7NxMMg=.470861cd-882f-4b09-82f6-e964c2675edb@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
 <M_4tDy-kW30qll_RCADRy0K3rfprlhudosTYe7NxMMg=.470861cd-882f-4b09-82f6-e964c2675edb@github.com>
Message-ID: <xupFHpiKvgYsymWi6daCGa0d32Tl2qN8bic69GjniGM=.c62f2508-7bcd-4e8e-9319-22a4a78c3daf@github.com>

On Thu, 7 Aug 2025 10:09:34 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Options for restore are now processed during the common VM arguments parsing stage.
>> 
>> Notable improvements compared to the old code:
>> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
>> - Option aliasing is now handled correctly
>> 
>> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.
>
> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix flag name comparison
>  - Handle aliased restore-settable boolean options

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

> 2969:     // Restored JVM will search for the flag using the name we record here so we
> 2970:     // must ensure the real one is recorded
> 2971:     if (strcmp(flag->name(), name) == 0) {

IIUC the `name` can still contain the equals sign and value? Maybe if you used the `stripped_name`...

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

PR Review Comment: https://git.openjdk.org/crac/pull/258#discussion_r2262627328

From tpushkin at openjdk.org  Fri Aug  8 11:13:05 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 11:13:05 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v5]
In-Reply-To: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
Message-ID: <04R-VodNZnI7N6NLR23ooFcooz6OPq2I1ZjcoJgWKa0=.61b55638-735a-4e19-b549-c79fbbdec889@github.com>

> New main is now launched after restoration completes solving the issues outlined in the JBS task.
> 
> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
> 
> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
> Exception in thread "main" jdk.crac.RestoreException
>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>                 at Main.main(Main.java:4)
>         Caused by: java.lang.ClassNotFoundException: app.jar
>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>                 at java.base/java.lang.Class.forName0(Native Method)
>                 at java.base/java.lang.Class.forName(Class.java:547)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>                 ... 3 more

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

  Use Asserts for exception validation

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

Changes:
  - all: https://git.openjdk.org/crac/pull/253/files
  - new: https://git.openjdk.org/crac/pull/253/files/fb5295f7..8f2cd6d1

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

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

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

From rvansa at openjdk.org  Fri Aug  8 11:31:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 11:31:31 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v5]
In-Reply-To: <04R-VodNZnI7N6NLR23ooFcooz6OPq2I1ZjcoJgWKa0=.61b55638-735a-4e19-b549-c79fbbdec889@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <04R-VodNZnI7N6NLR23ooFcooz6OPq2I1ZjcoJgWKa0=.61b55638-735a-4e19-b549-c79fbbdec889@github.com>
Message-ID: <WiCfQIaslzpCfLnikaMPj8HY9hR13m8Boqq7YetDmuc=.2b473a86-eb7f-4157-b1d7-b7959f90743a@github.com>

On Fri, 8 Aug 2025 11:13:05 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> New main is now launched after restoration completes solving the issues outlined in the JBS task.
>> 
>> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
>> 
>> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
>> Exception in thread "main" jdk.crac.RestoreException
>>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>>                 at Main.main(Main.java:4)
>>         Caused by: java.lang.ClassNotFoundException: app.jar
>>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>                 at java.base/java.lang.Class.forName0(Native Method)
>>                 at java.base/java.lang.Class.forName(Class.java:547)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>>                 ... 3 more
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Asserts for exception validation

OK, I meant this `assertEquals` would be put straight to the library, but this is fine by me.

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/253#pullrequestreview-3100448957

From rvansa at openjdk.org  Fri Aug  8 11:33:30 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 11:33:30 GMT
Subject: [crac] RFR: 8364456: [CRaC] Extend error logging of
 waitForCheckpointed
In-Reply-To: <nHlQImH0D2PYCZbHTIyGJ7nGxjxlHD8MCMqIYtTe4Gw=.41d7d692-7637-4855-8a00-c07a580c14ce@github.com>
References: <nHlQImH0D2PYCZbHTIyGJ7nGxjxlHD8MCMqIYtTe4Gw=.41d7d692-7637-4855-8a00-c07a580c14ce@github.com>
Message-ID: <fhASzJRbwEmT5cM9bQdY2Ld0uZsli6jmaVoD_CtSn0M=.9a3402e2-aac8-4973-a9e9-a55d23c93bf5@github.com>

On Thu, 31 Jul 2025 17:59:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `CracProcess.waitForCheckpointed()` print the same logs as `CracProcess.waitForSuccess()` does.
> 
> <details>
> 
> <summary>Before</summary>
> 
> 
> STDERR:
> Starting process to be checkpointed:
> <crac-repo>/build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp <crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:<crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest
> java.lang.RuntimeException: Checkpointed process was not killed as expected. expected: 137 but was: 1
>         at jdk.test.lib.Asserts.fail(Asserts.java:715)
>         at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
>         at jdk.test.lib.crac.CracProcess.waitForCheckpointed(CracProcess.java:41)
>         at jdk.test.lib.crac.CracBuilder.doCheckpoint(CracBuilder.java:241)
>         at CheckpointInNewMainTest.test(CheckpointInNewMainTest.java:53)
>         at jdk.test.lib.crac.CracTest.run(CracTest.java:163)
>         at jdk.test.lib.crac.CracTest.main(CracTest.java:90)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>         at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test
> 
> 
> </details>
> 
> <details>
> 
> <summary>After</summary>
> 
> 
> STDERR:
> Starting process to be checkpointed:
> <crac-repo>/build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp <crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:<crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest
> stdout: [
> ]
> stderr: [
> Exception in thread "main" java.lang.IllegalStateException: Some very useful explanation of the problem
>    ...

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/254#pullrequestreview-3100452989

From tpushkin at openjdk.org  Fri Aug  8 11:36:35 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 11:36:35 GMT
Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core
 C/R body [v5]
In-Reply-To: <04R-VodNZnI7N6NLR23ooFcooz6OPq2I1ZjcoJgWKa0=.61b55638-735a-4e19-b549-c79fbbdec889@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
 <04R-VodNZnI7N6NLR23ooFcooz6OPq2I1ZjcoJgWKa0=.61b55638-735a-4e19-b549-c79fbbdec889@github.com>
Message-ID: <wIorzSjqLEKwU7HWR9XlNw-ikkVBRIgb510m4S9J0KM=.5e0e7954-90b6-44ee-801c-2ca22dd285e2@github.com>

On Fri, 8 Aug 2025 11:13:05 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> New main is now launched after restoration completes solving the issues outlined in the JBS task.
>> 
>> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
>> 
>> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
>> Exception in thread "main" jdk.crac.RestoreException
>>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>>                 at Main.main(Main.java:4)
>>         Caused by: java.lang.ClassNotFoundException: app.jar
>>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>                 at java.base/java.lang.Class.forName0(Native Method)
>>                 at java.base/java.lang.Class.forName(Class.java:547)
>>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>>                 ... 3 more
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Asserts for exception validation

I figured since it is just for one test there is no need to touch mainline code.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/crac/pull/253#issuecomment-3167566902

From rvansa at openjdk.org  Fri Aug  8 11:42:39 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 11:42:39 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <tV0-a5FfgyUQaFaIJstIq8YIrtrHFhcUwLBblbOA4zg=.91529a75-780a-49fb-a9ca-7069d36925d6@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
 <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
 <tV0-a5FfgyUQaFaIJstIq8YIrtrHFhcUwLBblbOA4zg=.91529a75-780a-49fb-a9ca-7069d36925d6@github.com>
Message-ID: <YHMHoHQPDT_Kym-lYLXgqnW9V6eFS3rjEVtNGAXnKUc=.100f3820-d3e2-4aff-aacd-f257d27a7128@github.com>

On Tue, 5 Aug 2025 07:36:57 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1969:
>> 
>>> 1967:                                                                             \
>>> 1968:   product(uint, CRaCMinPid, 128,                                            \
>>> 1969:           "Mininal PID value for checkpointed process (Unix only)")         \
>> 
>> `Unix` -> `POSIX` (same as in java.md). Linux is not Unix.
>
> I agree but I am following the style of the file. In this file "(Unix only)" is used for 3 other options while "posix" is not used at all.

Understood, but that doesn't make it correct. Linux is still not Unix. Btw., should we move this to `globals_linux.hpp`?

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2262713840

From tpushkin at openjdk.org  Fri Aug  8 11:42:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 11:42:52 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser [v3]
In-Reply-To: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
Message-ID: <OdcGJJ8LPhuFSStnd8YwBOc6fr5uaBn3NwKoAxcSyc8=.55a3985d-9d60-4aef-b72a-095f13f077f4@github.com>

> Options for restore are now processed during the common VM arguments parsing stage.
> 
> Notable improvements compared to the old code:
> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
> - Option aliasing is now handled correctly
> 
> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.

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

  Fix name vs real name comparison

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

Changes:
  - all: https://git.openjdk.org/crac/pull/258/files
  - new: https://git.openjdk.org/crac/pull/258/files/3a1080b3..51e4d3dd

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

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

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

From rvansa at openjdk.org  Fri Aug  8 11:47:23 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 11:47:23 GMT
Subject: [crac] RFR: 8364662: [CRaC] Process restore options in the common
 arguments parser [v3]
In-Reply-To: <OdcGJJ8LPhuFSStnd8YwBOc6fr5uaBn3NwKoAxcSyc8=.55a3985d-9d60-4aef-b72a-095f13f077f4@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
 <OdcGJJ8LPhuFSStnd8YwBOc6fr5uaBn3NwKoAxcSyc8=.55a3985d-9d60-4aef-b72a-095f13f077f4@github.com>
Message-ID: <WvreJyy_NTegdtFrjrKt3_XscuMlK8uPQ43uQ19obfc=.3c536fd0-72c6-4b1f-94eb-92cb28ca67d6@github.com>

On Fri, 8 Aug 2025 11:42:52 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Options for restore are now processed during the common VM arguments parsing stage.
>> 
>> Notable improvements compared to the old code:
>> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
>> - Option aliasing is now handled correctly
>> 
>> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix name vs real name comparison

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/258#pullrequestreview-3100485062

From rvansa at openjdk.org  Fri Aug  8 12:11:30 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 12:11:30 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests
In-Reply-To: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
Message-ID: <_mULfGh0BsERV5vlD7B23KMHgyEfF5g2hyzS1qrbPWg=.90c78f17-019c-406b-b7f3-d203ac5e7041@github.com>

On Wed, 6 Aug 2025 15:32:01 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Stabilizes recompiler tests:
> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.

test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 147:

> 145:             @Override
> 146:             public void afterRestore(Context<? extends Resource> context) {
> 147:                 assertFalse(

Please break this into two `assertFalse` statements for clarity.

test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 163:

> 161:         // Utils.waitForCondition() invokes its supplier argument one more time
> 162:         // after it returns true. For our conditions that is unacceptable.
> 163:         final var result = new Object() { boolean value = false; };

TBH I would use `AtomicBoolean` for a mutable bool wrapper but YMMV.

test/jdk/jdk/crac/recompiler/RecompilationFlagsTest.java line 164:

> 162:             recompilerThread.join();
> 163:         } else {
> 164:             System.out.println("Recompiler thread not set");

You could assert that the thread is present or not based on the test parameters.

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

PR Review Comment: https://git.openjdk.org/crac/pull/259#discussion_r2262741275
PR Review Comment: https://git.openjdk.org/crac/pull/259#discussion_r2262753881
PR Review Comment: https://git.openjdk.org/crac/pull/259#discussion_r2262787566

From tpushkin at openjdk.org  Fri Aug  8 12:12:39 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:12:39 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <YHMHoHQPDT_Kym-lYLXgqnW9V6eFS3rjEVtNGAXnKUc=.100f3820-d3e2-4aff-aacd-f257d27a7128@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <HEGxiEJ0fBmwU8Cd7330lofPE-C3_GlFq0wOYmXGic0=.fafc157e-47f8-43bd-9b49-936a88b9852d@github.com>
 <ALCAKMHmkUjrBZSEEUAqiIe05vR6_Qzn3sokaBnApzM=.8fdd5925-94f8-4a79-b181-1e55e77014ce@github.com>
 <tV0-a5FfgyUQaFaIJstIq8YIrtrHFhcUwLBblbOA4zg=.91529a75-780a-49fb-a9ca-7069d36925d6@github.com>
 <YHMHoHQPDT_Kym-lYLXgqnW9V6eFS3rjEVtNGAXnKUc=.100f3820-d3e2-4aff-aacd-f257d27a7128@github.com>
Message-ID: <dRdpNGx8L_hA5L7TU_nF5qTe7rBQCR3GfpquGnOnVak=.d74983c6-fc2d-40a8-8db6-dca60815ca9c@github.com>

On Fri, 8 Aug 2025 11:39:39 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Understood, but that doesn't make it correct. Linux is still not Unix.

Ok, will redact.

> Btw., should we move this to `globals_linux.hpp`?

No, it is used on all platforms but Windows, and there is no `globals_posix.hpp`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2262797437

From tpushkin at openjdk.org  Fri Aug  8 12:13:17 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:13:17 GMT
Subject: [crac] RFR: 8365143: [CRaC] CRaCIgnoreRestoreIfUnavailable tests do
 not check exit value
Message-ID: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>

Adds missing exit value checks.

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

Commit messages:
 - Add missing waitForSuccess

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

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

From tpushkin at openjdk.org  Fri Aug  8 12:43:22 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:43:22 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
 <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>
Message-ID: <Y9oVDRRgEEzLWic992AUkN6I1faJ3EIQX8WtWt3nRX0=.7f47859a-b3f9-4f45-8d7e-71b6aafd09eb@github.com>

On Tue, 5 Aug 2025 09:48:58 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix CRaCSkipCheckpoint aliasing
>
> src/hotspot/share/runtime/arguments.cpp line 1:
> 
>> 1: /*
> 
> BTW maybe it is time to put expiration dates for all of CRaC's deprecated/obsoleted options? For each parsed argument there are linear searches through lists of special (deprecated/obsoleted/expired) and aliased flags `strcmp`-ing them which slows down argument parsing.
> 
> Since most of them have been deprecated since winter we can put 26 as the expiration version: it will be a year since the options were deprecated. For the ones deprecated/obsoleted today it can be 27.

Ended up expiring everything since 26: the options added to special in this PR are diagnostic/experimental and not widely used, so this is in accordance with OpenJDK's recommendations.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2262869028

From tpushkin at openjdk.org  Fri Aug  8 12:43:21 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:43:21 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v5]
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <HVdvGFRERxepoTGJ4lVhIZRkoZ9dDT3nkpPAxqyaup4=.5a3e5414-6b04-4b7b-a02c-caa8c75db1f9@github.com>

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Expire CRaC's special options since JDK 26
 - Replace Unix with POSIX

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

Changes:
  - all: https://git.openjdk.org/crac/pull/256/files
  - new: https://git.openjdk.org/crac/pull/256/files/e661cdf3..a92d9616

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

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

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

From tpushkin at openjdk.org  Fri Aug  8 12:47:30 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:47:30 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests
In-Reply-To: <_mULfGh0BsERV5vlD7B23KMHgyEfF5g2hyzS1qrbPWg=.90c78f17-019c-406b-b7f3-d203ac5e7041@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
 <_mULfGh0BsERV5vlD7B23KMHgyEfF5g2hyzS1qrbPWg=.90c78f17-019c-406b-b7f3-d203ac5e7041@github.com>
Message-ID: <S2TfE1lxytL45LWG2-m-Fkw_OZ1u2GYk8mfBLFjNaTo=.ed0d864a-20ba-49f5-855b-681401c4edf4@github.com>

On Fri, 8 Aug 2025 11:55:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Stabilizes recompiler tests:
>> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
>> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.
>
> test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 163:
> 
>> 161:         // Utils.waitForCondition() invokes its supplier argument one more time
>> 162:         // after it returns true. For our conditions that is unacceptable.
>> 163:         final var result = new Object() { boolean value = false; };
> 
> TBH I would use `AtomicBoolean` for a mutable bool wrapper but YMMV.

Since this used by a single thread I'll leave it as is.

I agree that `AtomicBoolean` may give better readability but it may also be confusing since it suggests some kind of concurrency.

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

PR Review Comment: https://git.openjdk.org/crac/pull/259#discussion_r2262878306

From tpushkin at openjdk.org  Fri Aug  8 12:55:28 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 12:55:28 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests
In-Reply-To: <_mULfGh0BsERV5vlD7B23KMHgyEfF5g2hyzS1qrbPWg=.90c78f17-019c-406b-b7f3-d203ac5e7041@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
 <_mULfGh0BsERV5vlD7B23KMHgyEfF5g2hyzS1qrbPWg=.90c78f17-019c-406b-b7f3-d203ac5e7041@github.com>
Message-ID: <JwfEn8deVMk7d5Oo08XaLsWhmxlrI9yFKBpqI7banoY=.22ab1ca5-9dab-4c35-857c-8774d80d84c0@github.com>

On Fri, 8 Aug 2025 12:08:06 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Stabilizes recompiler tests:
>> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
>> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.
>
> test/jdk/jdk/crac/recompiler/RecompilationFlagsTest.java line 164:
> 
>> 162:             recompilerThread.join();
>> 163:         } else {
>> 164:             System.out.println("Recompiler thread not set");
> 
> You could assert that the thread is present or not based on the test parameters.

This should actually never happen with the current implementation (the method is only used when the delay is used). I did it this way instead of `assertNotNull`in case we change the implementation to set the field to null after the thread finishes ? this will be a data race and the test will start failing sometimes.

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

PR Review Comment: https://git.openjdk.org/crac/pull/259#discussion_r2262893826

From tpushkin at openjdk.org  Fri Aug  8 13:08:51 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 13:08:51 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests [v2]
In-Reply-To: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
Message-ID: <D1iDaHIAROJ4Ls5utRBewSqVhUSC_afvxfvufC440rg=.545168ff-cc36-4543-b66c-bb08653587b6@github.com>

> Stabilizes recompiler tests:
> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.

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

  Improve assertions in NaturalDecompilationTest

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

Changes:
  - all: https://git.openjdk.org/crac/pull/259/files
  - new: https://git.openjdk.org/crac/pull/259/files/09cc0be9..8014e0ea

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

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

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

From tpushkin at openjdk.org  Fri Aug  8 13:10:01 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 13:10:01 GMT
Subject: [crac] Integrated: 8364456: [CRaC] Extend error logging of
 waitForCheckpointed
In-Reply-To: <nHlQImH0D2PYCZbHTIyGJ7nGxjxlHD8MCMqIYtTe4Gw=.41d7d692-7637-4855-8a00-c07a580c14ce@github.com>
References: <nHlQImH0D2PYCZbHTIyGJ7nGxjxlHD8MCMqIYtTe4Gw=.41d7d692-7637-4855-8a00-c07a580c14ce@github.com>
Message-ID: <iSFT9m41Mrz1LFxzY9SkwmJcw_Udm-NQVu_htcu_6cw=.4b63ca49-6dc4-483e-8374-bcb876012b75@github.com>

On Thu, 31 Jul 2025 17:59:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `CracProcess.waitForCheckpointed()` print the same logs as `CracProcess.waitForSuccess()` does.
> 
> <details>
> 
> <summary>Before</summary>
> 
> 
> STDERR:
> Starting process to be checkpointed:
> <crac-repo>/build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp <crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:<crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest
> java.lang.RuntimeException: Checkpointed process was not killed as expected. expected: 137 but was: 1
>         at jdk.test.lib.Asserts.fail(Asserts.java:715)
>         at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
>         at jdk.test.lib.crac.CracProcess.waitForCheckpointed(CracProcess.java:41)
>         at jdk.test.lib.crac.CracBuilder.doCheckpoint(CracBuilder.java:241)
>         at CheckpointInNewMainTest.test(CheckpointInNewMainTest.java:53)
>         at jdk.test.lib.crac.CracTest.run(CracTest.java:163)
>         at jdk.test.lib.crac.CracTest.main(CracTest.java:90)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>         at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test
> 
> 
> </details>
> 
> <details>
> 
> <summary>After</summary>
> 
> 
> STDERR:
> Starting process to be checkpointed:
> <crac-repo>/build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp <crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:<crac-repo>/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest
> stdout: [
> ]
> stderr: [
> Exception in thread "main" java.lang.IllegalStateException: Some very useful explanation of the problem
>    ...

This pull request has now been integrated.

Changeset: 1cfc81f3
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/1cfc81f3542be5eb94bcfbbfe7bce9614659941a
Stats:     16 lines in 1 file changed: 11 ins; 2 del; 3 mod

8364456: [CRaC] Extend error logging of waitForCheckpointed

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Fri Aug  8 16:04:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 16:04:32 GMT
Subject: [crac] Integrated: 8364449: [CRaC] Launch new main outside of the core
 C/R body
In-Reply-To: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com>
Message-ID: <aRHwTUDINBf14JDBJ2LnsmqJOZtYuG0nrJfpLHQJ0Dk=.fbaaefdd-75a0-498d-bc8b-0eb7ad7a709e@github.com>

On Thu, 31 Jul 2025 16:11:43 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> New main is now launched after restoration completes solving the issues outlined in the JBS task.
> 
> Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic:
> 
> $ java -XX:CRaCRestoreFrom=cr -jar app.jar
> Exception in thread "main" jdk.crac.RestoreException
>         Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution.
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263)
>                 at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73)
>                 at Main.main(Main.java:4)
>         Caused by: java.lang.ClassNotFoundException: app.jar
>                 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>                 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>                 at java.base/java.lang.Class.forName0(Native Method)
>                 at java.base/java.lang.Class.forName(Class.java:547)
>                 at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302)
>                 ... 3 more

This pull request has now been integrated.

Changeset: a2a82469
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/a2a824696e60c5e8f443982a2fc66d27f61e0e82
Stats:     516 lines in 6 files changed: 392 ins; 119 del; 5 mod

8364449: [CRaC] Launch new main outside of the core C/R body

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Fri Aug  8 16:08:39 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 16:08:39 GMT
Subject: [crac] RFR: 8364931: [CRaC] Stabilize recompiler tests [v2]
In-Reply-To: <D1iDaHIAROJ4Ls5utRBewSqVhUSC_afvxfvufC440rg=.545168ff-cc36-4543-b66c-bb08653587b6@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
 <D1iDaHIAROJ4Ls5utRBewSqVhUSC_afvxfvufC440rg=.545168ff-cc36-4543-b66c-bb08653587b6@github.com>
Message-ID: <Zm32sdRm1pOhQUcA_L2YbcIFSx5a3rCc7bixz0DcLpE=.3f605061-2cfe-40c1-9bc3-9c0a04527baf@github.com>

On Fri, 8 Aug 2025 13:08:51 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Stabilizes recompiler tests:
>> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
>> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve assertions in NaturalDecompilationTest

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/259#pullrequestreview-3101376528

From rvansa at openjdk.org  Fri Aug  8 16:14:34 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 8 Aug 2025 16:14:34 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <Y9oVDRRgEEzLWic992AUkN6I1faJ3EIQX8WtWt3nRX0=.7f47859a-b3f9-4f45-8d7e-71b6aafd09eb@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
 <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>
 <Y9oVDRRgEEzLWic992AUkN6I1faJ3EIQX8WtWt3nRX0=.7f47859a-b3f9-4f45-8d7e-71b6aafd09eb@github.com>
Message-ID: <dCHAi4vWd2nG91dW0c3syZsIn_NWhNv_QUY-FA6a9jw=.e970880e-684b-4383-a80c-bff53eac234c@github.com>

On Fri, 8 Aug 2025 12:40:23 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1:
>> 
>>> 1: /*
>> 
>> BTW maybe it is time to put expiration dates for all of CRaC's deprecated/obsoleted options? For each parsed argument there are linear searches through lists of special (deprecated/obsoleted/expired) and aliased flags `strcmp`-ing them which slows down argument parsing.
>> 
>> Since most of them have been deprecated since winter we can put 26 as the expiration version: it will be a year since the options were deprecated. For the ones deprecated/obsoleted today it can be 27.
>
> Ended up expiring everything since 26: the options added to special in this PR are diagnostic/experimental and not widely used, so this is in accordance with OpenJDK's recommendations.

Expiration by 26 is probably fine, but it seems that you're obsoleting retroactively? There is no 24-based version that would obsolete those, this will be ~25 and you're obsoleting on the spot. Except for `CRaCDoThrowCheckpointException` I would make these defunct (through expiration) only in 26.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2263410675

From tpushkin at openjdk.org  Fri Aug  8 17:30:38 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 17:30:38 GMT
Subject: git: openjdk/crac: crac: 8364662: [CRaC] Process restore options in
 the common arguments parser
Message-ID: <5b4bbc95-501a-4bf9-a96d-f20968483d23@openjdk.org>

Changeset: 30d91696
Branch: crac
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Date:      2025-08-08 17:28:55 +0000
URL:       https://git.openjdk.org/crac/commit/30d916967890b93c4e2eda54ca39b66e3001eaa2

8364662: [CRaC] Process restore options in the common arguments parser

Reviewed-by: rvansa

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/arguments.hpp
! src/hotspot/share/runtime/crac.cpp
! src/hotspot/share/runtime/threads.cpp
! test/jdk/jdk/crac/VMOptionsTest.java
! test/jdk/jdk/crac/engineOptions/ParsingTest.java
! test/jdk/jdk/crac/fileDescriptors/LoggingVMlogOpenTestNegative.java


From tpushkin at openjdk.org  Fri Aug  8 17:32:34 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 17:32:34 GMT
Subject: [crac] Integrated: 8364662: [CRaC] Process restore options in the
 common arguments parser
In-Reply-To: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
References: <_ovY0_5Ty-5yHoR_mP-1BBZih-hD9fynyeQ7U84yQN8=.11c11d82-89a1-4a4e-9af6-4bd996ae0311@github.com>
Message-ID: <rZZLyLeDbXQRynfCWfnRpaM55HdvaD9-_Xz4N5oHWYE=.c5960f8a-2b57-4e83-989e-75389a2d9b82@github.com>

On Mon, 4 Aug 2025 18:12:57 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Options for restore are now processed during the common VM arguments parsing stage.
> 
> Notable improvements compared to the old code:
> - Options from `-XX:Flags=<file>` and `-XX:VMOptionsFile=<file>` are now also considered
> - Option aliasing is now handled correctly
> 
> **Behavioral change**. If `CRaCIgnoreRestoreIfUnavailable` is true it is now not an error to specify non-restore-settable options on restore ? these will just be omitted from forwarding to the restored JVM. This makes it possible to specify non-restore-settable to be used after a failed restore.

This pull request has now been integrated.

Changeset: 30d91696
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/30d916967890b93c4e2eda54ca39b66e3001eaa2
Stats:     363 lines in 7 files changed: 216 ins; 100 del; 47 mod

8364662: [CRaC] Process restore options in the common arguments parser

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Fri Aug  8 17:52:26 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 17:52:26 GMT
Subject: [crac] Integrated: 8364931: [CRaC] Stabilize recompiler tests
In-Reply-To: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
References: <Kj_y9GctrHikcWEK0doNTaCYeu0l2Mzi56_CSR4evSg=.84ee317d-aacc-4a28-ad0f-ab2599990a33@github.com>
Message-ID: <YJ1jwcQMWl9bqGzu3gxdVv2WGNNrp4mLj0O1W2XJ1lc=.2dcf1125-b4d9-49fe-bc68-8757d95098cd@github.com>

On Wed, 6 Aug 2025 15:32:01 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Stabilizes recompiler tests:
> - `NaturalDecompilationTest` now ensures the method is not enqueued for another compilation before proceeding with the test.
> - In `RecompilationFlagsTest` recompilation waiting period of a predefined length is replaced with waiting for the methods to get enqueued and dequeued to/from the compilation queue.

This pull request has now been integrated.

Changeset: 85f0e22c
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/85f0e22c84dc7748626785cb944b95efbeaeec5d
Stats:     102 lines in 2 files changed: 64 ins; 16 del; 22 mod

8364931: [CRaC] Stabilize recompiler tests

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Fri Aug  8 19:03:14 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 19:03:14 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <dCHAi4vWd2nG91dW0c3syZsIn_NWhNv_QUY-FA6a9jw=.e970880e-684b-4383-a80c-bff53eac234c@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
 <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>
 <Y9oVDRRgEEzLWic992AUkN6I1faJ3EIQX8WtWt3nRX0=.7f47859a-b3f9-4f45-8d7e-71b6aafd09eb@github.com>
 <dCHAi4vWd2nG91dW0c3syZsIn_NWhNv_QUY-FA6a9jw=.e970880e-684b-4383-a80c-bff53eac234c@github.com>
Message-ID: <CAuv-pq4XB2mfwnwcsxI3e3Moy0MotBhjD37fUFHMvo=.c394e039-2cbe-4087-a37b-4a0163340e4d@github.com>

On Fri, 8 Aug 2025 16:11:40 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Ended up expiring everything since 26: the options added to special in this PR are diagnostic/experimental and not widely used, so this is in accordance with OpenJDK's recommendations.
>
> Expiration by 26 is probably fine, but it seems that you're obsoleting retroactively? There is no 24-based version that would obsolete those, this will be ~25 and you're obsoleting on the spot. Except for `CRaCDoThrowCheckpointException` I would make these defunct (through expiration) only in 26.

Oh, I really did not intend to do that. I was fighting version correctness asserts and misread the guidelines in `arguments.cpp`.

The guidelines state: "To change the name of an option, use the alias table as well as a 2-step model adding major release numbers to the deprecate and expire columns", but this seems to not be possible because asserts mandate that:
- it is not allowed to only fill deprecate and expire columns, obsolete must also be filled: "<flag> must be explicitly obsoleted before expired";
- it is not allowed to set obsolete and expire columns to the same version, expire must be strictly greater: "<flag> must be obsoleted before expired".

So only a 3-step model is possible. Since we do not want to obsolete on the spot for our aliases we can only either:
- If using only major versions, obsolete in 26 and expire in 27 (for LTS releases: April and October 2026)
- If using minor versions too, obsolete in 26 and expire in 26.0.2 (for LTS releases: April and July 2026)
   - We do not want to obsolete before 26 because that would be less than a year since the deprecation of frequently-used aliases
   - To correspond to LTS versions, we cannot obsolete in 26 and expire in 26.0.1 because in LTS that would be the same April 2026 release and we'll get assert failures because obsolete == expire

I do not have a preference: the first one looks cleaner, the second one makes the aliases expire sooner. Went with the first one just to choose something.

For `CRTrace` and `CRaCDoThrowCheckpointException` it is possible to expire in 26 so I did that.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2263792541

From tpushkin at openjdk.org  Fri Aug  8 19:03:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 8 Aug 2025 19:03:13 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v6]
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <1icK3-ZjlmQZIQyAReVTYy-oXvkcAjfHF89j7SpetZw=.65c6fcc9-af91-4f1c-94c8-da7463b0493b@github.com>

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Expire CRaC's special options - attempt 2
 - Revert "Expire CRaC's special options since JDK 26"
   
   This reverts commit a92d961609d1d96b479723787f035f13f8944d6e.

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

Changes:
  - all: https://git.openjdk.org/crac/pull/256/files
  - new: https://git.openjdk.org/crac/pull/256/files/a92d9616..a18c8299

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

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

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

From rvansa at openjdk.org  Mon Aug 11 07:45:37 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 11 Aug 2025 07:45:37 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v4]
In-Reply-To: <CAuv-pq4XB2mfwnwcsxI3e3Moy0MotBhjD37fUFHMvo=.c394e039-2cbe-4087-a37b-4a0163340e4d@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <9nT-p6q4qdEttHP1Etv70NBosYA85aXNOmtaeM65wNI=.62518e91-4c32-4cdd-a32e-5e4ebb9720ec@github.com>
 <qO2eGAm8c57301J45olKRK182YJcXPgyRU8_i_qo0jw=.714c0486-9c28-474e-9390-a5abdf6cef62@github.com>
 <Y9oVDRRgEEzLWic992AUkN6I1faJ3EIQX8WtWt3nRX0=.7f47859a-b3f9-4f45-8d7e-71b6aafd09eb@github.com>
 <dCHAi4vWd2nG91dW0c3syZsIn_NWhNv_QUY-FA6a9jw=.e970880e-684b-4383-a80c-bff53eac234c@github.com>
 <CAuv-pq4XB2mfwnwcsxI3e3Moy0MotBhjD37fUFHMvo=.c394e039-2cbe-4087-a37b-4a0163340e4d@github.com>
Message-ID: <w5ANrwdf1pNcBjl5KjmeNhoo0AHjQWcwwiczFNhJk5Y=.31ea7592-8aca-47a3-b33d-9d2bd177f900@github.com>

On Fri, 8 Aug 2025 18:57:32 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Expiration by 26 is probably fine, but it seems that you're obsoleting retroactively? There is no 24-based version that would obsolete those, this will be ~25 and you're obsoleting on the spot. Except for `CRaCDoThrowCheckpointException` I would make these defunct (through expiration) only in 26.
>
> Oh, I really did not intend to do that. I was fighting version correctness asserts and misread the guidelines in `arguments.cpp`.
> 
> The guidelines state: "To change the name of an option, use the alias table as well as a 2-step model adding major release numbers to the deprecate and expire columns", but this seems to not be possible because asserts mandate that:
> - it is not allowed to only fill deprecate and expire columns, obsolete must also be filled: "<flag> must be explicitly obsoleted before expired";
> - it is not allowed to set obsolete and expire columns to the same version, expire must be strictly greater: "<flag> must be obsoleted before expired".
> 
> So only a 3-step model is possible. Since we do not want to obsolete on the spot for our aliases we can only either:
> - If using only major versions, obsolete in 26 and expire in 27 (for LTS releases: April and October 2026)
> - If using minor versions too, obsolete in 26 and expire in 26.0.2 (for LTS releases: April and July 2026)
>    - We do not want to obsolete before 26 because that would be less than a year since the deprecation of frequently-used aliases
>    - To correspond to LTS versions, we cannot obsolete in 26 and expire in 26.0.1 because in LTS that would be the same April 2026 release and we'll get assert failures because obsolete == expire
> 
> I do not have a preference: the first one looks cleaner, the second one makes the aliases expire sooner. Went with the first one just to choose something.
> 
> For `CRTrace` and `CRaCDoThrowCheckpointException` it is possible to expire in 26 so I did that.

Let's stick to major versions, that's really cleaner. We don't really need to rush it.

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

PR Review Comment: https://git.openjdk.org/crac/pull/256#discussion_r2265924468

From rvansa at openjdk.org  Mon Aug 11 07:45:37 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 11 Aug 2025 07:45:37 GMT
Subject: [crac] RFR: 8364554: [CRaC] Improve CRaC VM options' docs [v6]
In-Reply-To: <1icK3-ZjlmQZIQyAReVTYy-oXvkcAjfHF89j7SpetZw=.65c6fcc9-af91-4f1c-94c8-da7463b0493b@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
 <1icK3-ZjlmQZIQyAReVTYy-oXvkcAjfHF89j7SpetZw=.65c6fcc9-af91-4f1c-94c8-da7463b0493b@github.com>
Message-ID: <Qkmkb3ZvxrUZSfWVAJM3MO7PUasrZXENzuJy3ZHCfZc=.45ea2df9-4ff6-4cdf-b505-d7676342ec1b@github.com>

On Fri, 8 Aug 2025 19:03:13 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Besides some wording and formatting of VM options:
>> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
>> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value
>
> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Expire CRaC's special options - attempt 2
>  - Revert "Expire CRaC's special options since JDK 26"
>    
>    This reverts commit a92d961609d1d96b479723787f035f13f8944d6e.

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/256#pullrequestreview-3104528808

From tpushkin at openjdk.org  Mon Aug 11 08:29:30 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 08:29:30 GMT
Subject: [crac] Integrated: 8364554: [CRaC] Improve CRaC VM options' docs
In-Reply-To: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
References: <jnGYasFxljetdQixI1aTFzFLRIXisM-5aOC9ftwVaQI=.8fba1c16-8f3a-478f-b309-4138d7780800@github.com>
Message-ID: <RxoRZJAR6MgXti_wI7Z-f8tnhKF6YDyOp-JsPLLHX7U=.55591cdd-66d3-4628-bd7d-acfd141a39e1@github.com>

On Fri, 1 Aug 2025 19:22:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Besides some wording and formatting of VM options:
> - Renames `CRaCAllowToSkipCheckpoint` to `CRaCSkipCheckpoint` since it makes the VM always skip checkpoints and not only in some cases
> - Replaces `CRaCMaxHeapSizeBeforeCheckpoint == 0` with `FLAG_IS_DEFAULT(CRaCMaxHeapSizeBeforeCheckpoint)` because the docs 0 do not specify 0 as a special value

This pull request has now been integrated.

Changeset: e49eb2bd
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/e49eb2bde98c5678a7874f611d0a16bf5db02c3c
Stats:     80 lines in 9 files changed: 8 ins; 9 del; 63 mod

8364554: [CRaC] Improve CRaC VM options' docs

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Mon Aug 11 11:21:06 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 11:21:06 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
Message-ID: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>

Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.

Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

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

Commit messages:
 - Ignore new args with CRaCIgnoreRestoreIfUnavailable

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

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

From tpushkin at openjdk.org  Mon Aug 11 14:21:43 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 14:21:43 GMT
Subject: [crac] RFR: 8365143: [CRaC] CRaCIgnoreRestoreIfUnavailable tests
 do not check exit value
In-Reply-To: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
References: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
Message-ID: <VM89ZMFWB8mCAGURoLSrf1BgpMWpr5sSOYIchDW9B8c=.8fc15550-115f-4fde-825a-bfabc42dbfca@github.com>

On Fri, 8 Aug 2025 12:06:08 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds missing exit value checks.

Turns out one of the tests has actually been failing on static build, Will look into it, looks like it fails because `crexec` is not a separate dynamic library in static builds.

Actually, the failure is not caused by this change. #255 and #257 just were merged separately and turns out they are conflicting (one of the tests was not prepared for a static build). So I am reopening this PR and will fix the failure separately.

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

PR Comment: https://git.openjdk.org/crac/pull/260#issuecomment-3173409010
PR Comment: https://git.openjdk.org/crac/pull/260#issuecomment-3175062229

From tpushkin at openjdk.org  Mon Aug 11 14:23:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 14:23:32 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
In-Reply-To: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
Message-ID: <EApJyuM4CirAj5rS3jl7mwYCERL-txdnHsF8XZ6pfIM=.2eb7867c-9e7e-494d-8f82-e5292e365480@github.com>

On Mon, 11 Aug 2025 11:14:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
> 
> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

The test failure is not related to this change

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

PR Comment: https://git.openjdk.org/crac/pull/261#issuecomment-3175069099

From rvansa at openjdk.org  Mon Aug 11 14:37:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 11 Aug 2025 14:37:31 GMT
Subject: [crac] RFR: 8365143: [CRaC] CRaCIgnoreRestoreIfUnavailable tests
 do not check exit value
In-Reply-To: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
References: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
Message-ID: <LCYbJEKHTm7Pz97Ot98ZnC3tK5N0DkC2HIOdLT3pewU=.d918346a-7a67-474c-9ae8-9d1ba96b388d@github.com>

On Fri, 8 Aug 2025 12:06:08 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds missing exit value checks.

LGTM

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/260#pullrequestreview-3106210339

From rvansa at openjdk.org  Mon Aug 11 14:41:33 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 11 Aug 2025 14:41:33 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
In-Reply-To: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
Message-ID: <nBoWiOTgNXb7tK-w2P9dZF8IBP1ZNU6aqRAGxkInraU=.b7d76710-e2b9-4a2f-8f17-52e8d07cd375@github.com>

On Mon, 11 Aug 2025 11:14:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
> 
> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

src/java.base/share/man/java.md line 1099:

> 1097:     instead of failing.
> 1098: 
> 1099:     When restoring with this option, you should specify a main class and its

> you **should** specify a main class

I guess we shall make this mandatory -> you **must** sepecify a main class? Do we have a test for the case when you run plain `java -XX:CRaCRestoreFrom=... -XX:+CRaCIgnoreRestoreIfUnavailable` and the image is not present?

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

PR Review Comment: https://git.openjdk.org/crac/pull/261#discussion_r2266993284

From tpushkin at openjdk.org  Mon Aug 11 14:42:37 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 14:42:37 GMT
Subject: [crac] Integrated: 8365143: [CRaC] CRaCIgnoreRestoreIfUnavailable
 tests do not check exit value
In-Reply-To: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
References: <IkMt2o8gHynug4-Y-0VsrRvrc8AMztbb13_1Gz6o-Bc=.b322af2b-ccdf-4362-b6f2-0f0aedd6e335@github.com>
Message-ID: <WntQaQZMuopQuclZcxXitG8GvCwwtu7AxpQGx8W6x9k=.14261734-6ecd-47c3-80d0-a4baef0f45f2@github.com>

On Fri, 8 Aug 2025 12:06:08 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Adds missing exit value checks.

This pull request has now been integrated.

Changeset: 62fc1fe7
Author:    Timofei Pushkin <tpushkin at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/62fc1fe79e5327dcc7217bbf934b819eb24fdb54
Stats:     9 lines in 4 files changed: 4 ins; 0 del; 5 mod

8365143: [CRaC] CRaCIgnoreRestoreIfUnavailable tests do not check exit value

Reviewed-by: rvansa

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

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

From tpushkin at openjdk.org  Mon Aug 11 14:56:27 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 11 Aug 2025 14:56:27 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
In-Reply-To: <nBoWiOTgNXb7tK-w2P9dZF8IBP1ZNU6aqRAGxkInraU=.b7d76710-e2b9-4a2f-8f17-52e8d07cd375@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
 <nBoWiOTgNXb7tK-w2P9dZF8IBP1ZNU6aqRAGxkInraU=.b7d76710-e2b9-4a2f-8f17-52e8d07cd375@github.com>
Message-ID: <1G4PgxsSqguqLUvLDw3gux-ZkwEiha2RG6V6oJQhZvE=.83e1af93-6ae4-4a01-9a7e-910f34f976fc@github.com>

On Mon, 11 Aug 2025 14:39:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
>> 
>> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.
>
> src/java.base/share/man/java.md line 1099:
> 
>> 1097:     instead of failing.
>> 1098: 
>> 1099:     When restoring with this option, you should specify a main class and its
> 
>> you **should** specify a main class
> 
> I guess we shall make this mandatory -> you **must** sepecify a main class? Do we have a test for the case when you run plain `java -XX:CRaCRestoreFrom=... -XX:+CRaCIgnoreRestoreIfUnavailable` and the image is not present?

No, there is no such test currently.

You do not always have to specify a main class since if the image exists the main won't be used. Initially I wrote "you are expected to specify" and made it shorter into this version.

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

PR Review Comment: https://git.openjdk.org/crac/pull/261#discussion_r2267037373

From jkratochvil at openjdk.org  Mon Aug 11 18:19:30 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 11 Aug 2025 18:19:30 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
In-Reply-To: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
Message-ID: <GFNtuW9LLsSqZxhPZ4KhptypFesLBfHUJHuVZfkWeII=.afe35dc0-80be-4772-b2dd-0d88a930a33f@github.com>

On Mon, 11 Aug 2025 11:14:56 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
> 
> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

Is there a use case when the passed new arguments/main *are* useful? Is there a s testcase for it? (I have been quickly searching it now but I haven't found it.)

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

PR Comment: https://git.openjdk.org/crac/pull/261#issuecomment-3176259090

From tpushkin at openjdk.org  Tue Aug 12 07:05:40 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 12 Aug 2025 07:05:40 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true
In-Reply-To: <GFNtuW9LLsSqZxhPZ4KhptypFesLBfHUJHuVZfkWeII=.afe35dc0-80be-4772-b2dd-0d88a930a33f@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
 <GFNtuW9LLsSqZxhPZ4KhptypFesLBfHUJHuVZfkWeII=.afe35dc0-80be-4772-b2dd-0d88a930a33f@github.com>
Message-ID: <Uc0TQFVOvPrfM9wYsyIy269r74VFs8c4iokEKY24dPE=.074122fb-a342-403c-afcd-951d7bcbdc78@github.com>

On Mon, 11 Aug 2025 18:16:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
>> 
>> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.
>
> Is there a use case when the passed new arguments/main *are* useful? Is there a s testcase for it? (I have been quickly searching it now but I haven't found it.)

@jankratochvil There is a demo `src/demo/share/crac/JavaCompilerCRaC` which you use as described here https://github.com/openjdk/crac/pull/16#issuecomment-1036140922.

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

PR Comment: https://git.openjdk.org/crac/pull/261#issuecomment-3177971287

From tpushkin at openjdk.org  Tue Aug 12 07:26:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 12 Aug 2025 07:26:13 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true [v2]
In-Reply-To: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
Message-ID: <N4EppFTXX1LDcN1d72JhZXTCoF3U-QJfAH68IHgiDhg=.6a02b963-a60d-432f-88c3-16a4ebb84473@github.com>

> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
> 
> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'openjdk-crac/crac' into ignore-new-args
 - Ignore new args with CRaCIgnoreRestoreIfUnavailable

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

Changes: https://git.openjdk.org/crac/pull/261/files
  Webrev: https://webrevs.openjdk.org/?repo=crac&pr=261&range=01
  Stats: 32 lines in 3 files changed: 26 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/crac/pull/261.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/261/head:pull/261

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

From tpushkin at openjdk.org  Wed Aug 13 06:42:04 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 13 Aug 2025 06:42:04 GMT
Subject: [crac] RFR: 8365380: [CRaC] Require non-static JDK for
 EngineFailureTest
Message-ID: <iSrd1SQXwJKpxHJoIhdqxXBS9PsLpz5sFTPUHUfBxdA=.9c52c03c-732e-436c-aacc-efb8dc99c9fb@github.com>

Requires a non-static JDK to run `EngineFailureTest`.

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

Commit messages:
 - Require non-static JDK for EngineFailureTest

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

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

From tpushkin at openjdk.org  Wed Aug 13 12:36:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 13 Aug 2025 12:36:52 GMT
Subject: [crac] RFR: 8365484: [CRaC] Support IgnoreUnrecognizedVMOptions on
 restore
Message-ID: <0YbpvDdaLySetDJhCGb5QfeTLahTRW7N7eoG5DyiPW4=.7e56a3f3-af2d-400c-98c1-f9acbe505eb6@github.com>

Makes `IgnoreUnrecognizedVMOptions` restore-settable.

`IgnoreUnrecognizedVMOptions` is not forwarded to the restored JVM since that does not make much sense.

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

Commit messages:
 - Make IgnoreUnrecognizedVMOptions restore-settable

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

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

From tpushkin at openjdk.org  Wed Aug 13 12:36:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 13 Aug 2025 12:36:52 GMT
Subject: [crac] RFR: 8365484: [CRaC] Support IgnoreUnrecognizedVMOptions on
 restore
In-Reply-To: <0YbpvDdaLySetDJhCGb5QfeTLahTRW7N7eoG5DyiPW4=.7e56a3f3-af2d-400c-98c1-f9acbe505eb6@github.com>
References: <0YbpvDdaLySetDJhCGb5QfeTLahTRW7N7eoG5DyiPW4=.7e56a3f3-af2d-400c-98c1-f9acbe505eb6@github.com>
Message-ID: <c81ONVZJAvejiA7AhYGDxiqTNUU025trXvrhugPPHFs=.a3451956-dbc5-4684-96e5-b32e93302e7b@github.com>

On Wed, 13 Aug 2025 12:29:47 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Makes `IgnoreUnrecognizedVMOptions` restore-settable.
> 
> `IgnoreUnrecognizedVMOptions` is not forwarded to the restored JVM since that does not make much sense.

A test fails because #262 is not integrated yet.

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

PR Comment: https://git.openjdk.org/crac/pull/263#issuecomment-3183718886

From tpushkin at openjdk.org  Thu Aug 14 08:03:14 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 14 Aug 2025 08:03:14 GMT
Subject: [crac] RFR: 8365241: [CRaC] Ignore new arguments when
 CRaCIgnoreRestoreIfUnavailable is true [v3]
In-Reply-To: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
References: <M7H0waGH40lwYnqIHbRUo5NEvfaDkGyttfZVkzApJrQ=.5a665310-b4f3-4e8f-b8be-d8e7b93d60c7@github.com>
Message-ID: <vUun8BH2B1CVOLADGCpCqAJ3Ab8TsnV0skdHMaWrGq8=.e2bc7e6c-32e6-44cd-99ab-afc3eba3b878@github.com>

> Arguments are not passed to the restored process when `-XX:+CRaCIgnoreRestoreIfUnavailable` is set on restore. The check is performed on the side of the restoring VM since in the restored VM `CRaCIgnoreRestoreIfUnavailable` could have been set before the current restore.
> 
> Documentation for the new arguments feature and `CRaCIgnoreRestoreIfUnavailable` is also added, explaining this behavior.

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

  Clarify CRaCIgnoreRestoreIfUnavailable guarantees

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

Changes:
  - all: https://git.openjdk.org/crac/pull/261/files
  - new: https://git.openjdk.org/crac/pull/261/files/d8c4e649..4897be1d

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

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

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