From duke at openjdk.org  Tue Jan  2 04:52:00 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 04:52:00 GMT
Subject: [crac] Withdrawn: Fix CPUFeatures crash on new->old CPU
In-Reply-To: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
Message-ID: <cfXKVWBERQ5baX9csPiRRqXev0_MDDG7N3-N9ngd2fY=.602cab12-34aa-45a3-8759-9a15b2c860ef@github.com>

On Wed, 25 Oct 2023 15:09:58 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> - reproducible on i7-1165G7 "qemu-kvm -cpu host" for a checkpoint and "qemu-kvm -cpu SandyBridge" for its restore

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 04:56:06 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 04:56:06 GMT
Subject: [crac] Withdrawn: Fix: arguments supplied to restore are split with
 whitespace
In-Reply-To: <zfcPRTx8R1W_ZAdQCR4l3lNa5wFo_HzbRv8t7B5PlP0=.eb57a00b-64bf-48fd-bacc-9087d3c344c1@github.com>
References: <zfcPRTx8R1W_ZAdQCR4l3lNa5wFo_HzbRv8t7B5PlP0=.eb57a00b-64bf-48fd-bacc-9087d3c344c1@github.com>
Message-ID: <rVs_K8MBe4vulz6Tb8ki3QV3m6pnKg-vrO4NlDuVbNE=.e8fd9d30-f4f9-43cd-bbb9-871f7fd2aee8@github.com>

On Thu, 10 Aug 2023 16:02:32 GMT, YizhePKU <duke at openjdk.org> wrote:

> This PR fixes a bug that causes arguments with whitespaces to be split into multiple arguments during restore.
> 
> It contains two commits. The first commit is refactor only. It moves all side effects from `CracRestoreParameters` to the call sites, and changes the type of `CracRestoreParameters::args` from a single string to a `GrowableArray` of strings. Serialization code is also cleaned up a bit.
> 
> The second commit fixes the bug by introducing a new pseudo property, `-DCRaCJavaMainArgs`, that is set in `JavaMain`. An instance of `JavaMainArgs` (containing `argc` and `argv`) is stored as extra info of the property, which is later extracted in `Arguments::parse_options_for_restore` and passed to `crac::restore`.
> 
> Potential issues:
> 
> * We use `putenv` to modify environment variables, which expects `char*`. In this PR, I'm `const_cast`ing from `const char*` to `char*`, since I believe `putenv` doesn't actually modify the string. Is that OK? Maybe rewriting with `setenv` would be better?
> * `read_growable_array` is implemented by reading byte-at-a-time from the shared memory. Will it be too slow? I could rewrite it to read everything at once (like the original code did), but the current implementation is cute and I kinda want to keep it.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 04:57:01 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 04:57:01 GMT
Subject: [crac] Withdrawn: Update copyrights
In-Reply-To: <zb7SOdjIMc0OTc1fUttZNszyh7bFTKyLovEtu2Eyevg=.ab223533-a600-4a3a-bb74-76e8d615964f@github.com>
References: <zb7SOdjIMc0OTc1fUttZNszyh7bFTKyLovEtu2Eyevg=.ab223533-a600-4a3a-bb74-76e8d615964f@github.com>
Message-ID: <klXyrC7cIzTF1gS2bm2CAChDCeipLhIDJzOCOyar1EE=.3d2869f1-1260-466a-a546-1ffb178dbcbe@github.com>

On Fri, 4 Aug 2023 11:29:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Add missing copyrights and licenses.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 04:58:11 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 04:58:11 GMT
Subject: [crac] Withdrawn: Linux file system watcher support
In-Reply-To: <QHZcGo5mRCsfuduSaDm7jCFi_nLpyYcXfYHLtpMR2hM=.fd058a3b-7530-4489-bbfb-0d7910cab245@github.com>
References: <QHZcGo5mRCsfuduSaDm7jCFi_nLpyYcXfYHLtpMR2hM=.fd058a3b-7530-4489-bbfb-0d7910cab245@github.com>
Message-ID: <Nfr_-MJHfFkJk__Jk6rekhWB5ydA8FPq2HEleHhl1Qw=.f5486ef7-500b-4b64-afb8-61a79e4195b5@github.com>

On Sun, 14 May 2023 10:00:26 GMT, joeylee <duke at openjdk.org> wrote:

> inotify monitors changes on filesystem, this support automatic restore for LinuxFileWatcher.
> 
> FileWatcherAfterRestoreTest verifies watcher service works after restore.
> FileWatcherTest verifies automatic closing inotiify fd
> 
> The watcher keys are still managed by user, so exception will be thrown if no watcher keys are leaked, as in FileWatcherWithOpenKeysTest

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 04:59:03 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 04:59:03 GMT
Subject: [crac] Withdrawn: Refactored javadocs with additional details
In-Reply-To: <Xasv2jKo27Xzj6VYDMLrQuzHOdz_EQjdAI78C0umBSc=.eb73f7d9-d475-4ef0-b548-c9d1a36089ec@github.com>
References: <Xasv2jKo27Xzj6VYDMLrQuzHOdz_EQjdAI78C0umBSc=.eb73f7d9-d475-4ef0-b548-c9d1a36089ec@github.com>
Message-ID: <birwG925A9imUZjkxgZG32h39s7zwEqNXUwip8wDfnw=.544c7e9b-f0cb-4724-8872-02520fe489c9@github.com>

On Wed, 10 May 2023 12:39:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Improve API documentation.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 05:00:10 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 05:00:10 GMT
Subject: [crac] Withdrawn: RCU Lock - RW lock with very lightweight read- and
 heavyweight write-locking
In-Reply-To: <wxetLQOu_xwhq0UUVKJwLY0-r8OVLcigl-VKnPDqncM=.d026a5b0-d4bd-42dc-8a97-9b8f880f86e3@github.com>
References: <wxetLQOu_xwhq0UUVKJwLY0-r8OVLcigl-VKnPDqncM=.d026a5b0-d4bd-42dc-8a97-9b8f880f86e3@github.com>
Message-ID: <NYtvH05mDnyNwSzMB-Jr5BRndVl35j8oBa9jc97g2m8=.fe07924b-f3d4-4ebc-b190-79d83ccee4ad@github.com>

On Wed, 12 Apr 2023 08:57:48 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This implementation is suitable for uses where the write-locking happens very rarely (if at all), as in the case of CRaC checkpoint, and we don't want to slow down regular access to the protected resource.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Jan  2 05:01:04 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 05:01:04 GMT
Subject: [crac] Withdrawn: Support repeated checkpoint and restore operations
In-Reply-To: <HyR2U6wuDtyUvxdJAfIglIy9wZKv4Dtu8LY1c81tQEc=.149964dd-81b4-4607-af02-91c9de235c70@github.com>
References: <HyR2U6wuDtyUvxdJAfIglIy9wZKv4Dtu8LY1c81tQEc=.149964dd-81b4-4607-af02-91c9de235c70@github.com>
Message-ID: <t-GnYiMrhPrjcOjqpsWyPE-OWZDhL7bJBKLm9GEqaYE=.ed5dafc0-1d28-4c16-9893-13ab3e72840f@github.com>

On Thu, 6 Apr 2023 11:51:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> * VM option CRaCCheckpointTo is recognized when restoring the application (destination can be changed)
> * The main problem for checkpoint after restore was old checkpoint image mmapped to files (CRaC-specific CRIU optimization for faster boot). Before performing checkpoint we transparently swap this with memory using anonymous mapping.

This pull request has been closed without being integrated.

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

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

From rvansa at openjdk.org  Tue Jan  2 09:32:05 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 2 Jan 2024 09:32:05 GMT
Subject: [crac] RFR: Improve C/R exception printout
In-Reply-To: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
References: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
Message-ID: <0WKBBQ9EyxfR1dyF1c5riECJL85_FqQWB7xwNaEccpo=.38f7d1d8-baf2-42da-9940-0a14df241426@github.com>

On Fri, 24 Nov 2023 09:04:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Some users might get confused by the inner exceptions reported during C/R as *suppressed* exceptions. This PR changes the printout to make it look as if the exception had multiple causes. For example the DryRunTest will report this:
> 
> jdk.crac.CheckpointException: Failed with 2 inner exceptions
> Cause 1/2: java.lang.RuntimeException: should not pass
> 	at DryRunTest$CRResource.beforeCheckpoint(DryRunTest.java:47)
> 	at java.base/jdk.crac.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:44)
> 	... (redacted)
> Cause 2/2: jdk.crac.impl.CheckpointOpenFileException: /tmp/jtreg-DryRunTest6956725915963168340.tmp
> 	at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$1(JDKFileResource.java:89)
> 	at java.base/jdk.crac.Core.checkpointRestore1(Core.java:174)
>         ... (redacted)

@AntonKozlov Could you review please?

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

PR Comment: https://git.openjdk.org/crac/pull/145#issuecomment-1873784611

From rvansa at openjdk.org  Tue Jan  2 10:03:04 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 2 Jan 2024 10:03:04 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <LrrFfxgKaXH7VkOurnKl3YUVRZyhTNLC_Mt6kugYiqU=.39adf162-bf3d-4afa-b917-01da17f7f7a9@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

In retrospective, I think that adding those extra parameters to CREngine was a mistake. I overgeneralized the need to pass some options to enable verbose logging (and TBH missed that underdocumented `CRAC_CRIU_OPTS` hack). Rather than passing something criuengine-specific, logging should have own option independent of CRIU, or even better, fetch settings from JVM unified logging.

Do you have many CRIU versions present in your system, or why are you interested in logging the exact paths? The parameters passed to CRIU don't change much, and CRIU in itself is an implementation detail. Why do you think it's useful to print it out regularly?

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1873817600

From akozlov at openjdk.org  Tue Jan  2 16:27:03 2024
From: akozlov at openjdk.org (Anton Kozlov)
Date: Tue, 2 Jan 2024 16:27:03 GMT
Subject: [crac] RFR: Improve C/R exception printout
In-Reply-To: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
References: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
Message-ID: <1WOxyVj1Bi4DI3hGBsvBGjMUU_ITdtD60sK8lwcm4HM=.45891427-4ae2-4cbb-92b2-22946684dae1@github.com>

On Fri, 24 Nov 2023 09:04:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Some users might get confused by the inner exceptions reported during C/R as *suppressed* exceptions. This PR changes the printout to make it look as if the exception had multiple causes. For example the DryRunTest will report this:
> 
> jdk.crac.CheckpointException: Failed with 2 inner exceptions
> Cause 1/2: java.lang.RuntimeException: should not pass
> 	at DryRunTest$CRResource.beforeCheckpoint(DryRunTest.java:47)
> 	at java.base/jdk.crac.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:44)
> 	... (redacted)
> Cause 2/2: jdk.crac.impl.CheckpointOpenFileException: /tmp/jtreg-DryRunTest6956725915963168340.tmp
> 	at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$1(JDKFileResource.java:89)
> 	at java.base/jdk.crac.Core.checkpointRestore1(Core.java:174)
>         ... (redacted)

Thanks. I agree that reporting exceptions as suppressed may be confusing. The new report looks good. But it introduces a new term "inner" which is not specified anywhere. Another side of the same problem is that programmatic access to the "inner" exception still remains through getSuppressed(), per javadoc and the fact there is no other mean to get an inner exception. I would suggest to go away completely from suppression (which was introduced for try-with-resources) to a completely distinct mechanism to record inner/nested/causing exceptions for Checkpoint... or RestoreException. How does it sound? My point is to have a mechanism that is consistent in 1) user-visible report; 2) in programmatic API; 3) the textual part of javadoc specification, e.g. package-level javadoc [1]. 

[1]https://github.com/openjdk/crac/blob/474b1638568a1a84b10d3b0a821e5d6e37f9eeae/src/java.base/share/classes/jdk/crac/package-info.java#L63

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

PR Comment: https://git.openjdk.org/crac/pull/145#issuecomment-1874246068

From rvansa at openjdk.org  Wed Jan  3 14:02:06 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 3 Jan 2024 14:02:06 GMT
Subject: [crac] RFR: Improve C/R exception printout
In-Reply-To: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
References: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
Message-ID: <sYbm5rk8d8CH5ucHJpj7ajKoafE0YC8Wx_HCCAmkBLQ=.322fcb76-54ec-49dd-97dc-2f977d5fa6f2@github.com>

On Fri, 24 Nov 2023 09:04:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Some users might get confused by the inner exceptions reported during C/R as *suppressed* exceptions. This PR changes the printout to make it look as if the exception had multiple causes. For example the DryRunTest will report this:
> 
> jdk.crac.CheckpointException: Failed with 2 inner exceptions
> Cause 1/2: java.lang.RuntimeException: should not pass
> 	at DryRunTest$CRResource.beforeCheckpoint(DryRunTest.java:47)
> 	at java.base/jdk.crac.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:44)
> 	... (redacted)
> Cause 2/2: jdk.crac.impl.CheckpointOpenFileException: /tmp/jtreg-DryRunTest6956725915963168340.tmp
> 	at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$1(JDKFileResource.java:89)
> 	at java.base/jdk.crac.Core.checkpointRestore1(Core.java:174)
>         ... (redacted)

"Nested" is probably a better term than "inner". Having method `getNestedExceptions()` that actually calls `getSuppressed()` would be trivial, and would provide space for javadocs. A completely distinct field is probably cleaner, though; however it feels that we are getting more code duplicated for Checkpoint and RestoreException; do you think it would be useful to have them share a common parent? (ofc. we will still have some duplication with the `javax.crac` package...).

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

PR Comment: https://git.openjdk.org/crac/pull/145#issuecomment-1875411980

From akozlov at openjdk.org  Wed Jan  3 15:21:13 2024
From: akozlov at openjdk.org (Anton Kozlov)
Date: Wed, 3 Jan 2024 15:21:13 GMT
Subject: [crac] RFR: Improve C/R exception printout
In-Reply-To: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
References: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
Message-ID: <6VemRfb0K-22KP_EiIQsXQfThyDVxDS6TUU_G_XdVVg=.09cb087c-edd6-4e64-916e-cc388845d640@github.com>

On Fri, 24 Nov 2023 09:04:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Some users might get confused by the inner exceptions reported during C/R as *suppressed* exceptions. This PR changes the printout to make it look as if the exception had multiple causes. For example the DryRunTest will report this:
> 
> jdk.crac.CheckpointException: Failed with 2 inner exceptions
> Cause 1/2: java.lang.RuntimeException: should not pass
> 	at DryRunTest$CRResource.beforeCheckpoint(DryRunTest.java:47)
> 	at java.base/jdk.crac.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:44)
> 	... (redacted)
> Cause 2/2: jdk.crac.impl.CheckpointOpenFileException: /tmp/jtreg-DryRunTest6956725915963168340.tmp
> 	at java.base/jdk.internal.crac.JDKFileResource.lambda$beforeCheckpoint$1(JDKFileResource.java:89)
> 	at java.base/jdk.crac.Core.checkpointRestore1(Core.java:174)
>         ... (redacted)

I also would prefer "nested" exceptions not to overlap with suppressed in implementation, to make sure the correct interface is always called. Indeed, a common parent class makes sense, and sometime in handling of the exception I had to write

catch (CheckpointException | RestoreException e) { ... }


Which is probably correct way to indicate both checkpoint and restore failures are handled there. But if you want to just to print the "nested" exception, apprantly you'll need a common base exception. I.e. a common base looks good.

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

PR Comment: https://git.openjdk.org/crac/pull/145#issuecomment-1875536319

From kyukihiro at openjdk.org  Fri Jan  5 12:57:02 2024
From: kyukihiro at openjdk.org (Kimura Yukihiro)
Date: Fri, 5 Jan 2024 12:57:02 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <Lx1eWNp_dR7J8OGORuoCxnpif3iJIF8t1mOfNsXf63s=.4ff8d817-3bab-45a2-9ab7-0521bf2d9664@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

I assume that some vendors provide the CRAC JDK, and other end users use them. 
When the JDK vendors support CRaC, I thought they might want to know from the logs how the end users specified CREngine, CRAC_CRIU_OPTS, CRTOOLS_SCRIPT_ACTION, etc.

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1878619569

From rvansa at openjdk.org  Fri Jan  5 13:51:56 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 5 Jan 2024 13:51:56 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <C52-6NIcDKn4doky-0gPPKDL2JElDwR-QIg2yLfU90g=.976c66fc-981a-4fe6-ac63-f84e3f158604@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

Maybe the `CREngine` should be guarded by the `UnlockDiagnosticVMOptions` flag; all these ways are very low-level 'expert' options.

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1878688179

From akozlov at openjdk.org  Fri Jan  5 17:15:51 2024
From: akozlov at openjdk.org (Anton Kozlov)
Date: Fri, 5 Jan 2024 17:15:51 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <jYrTyBHdJC8r13Xc-19pRT8tlZ3V5fxhYlydrcFDD-g=.0c5476ba-2557-4b90-b4c8-6b866857e697@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

Printing out implicitly set command line parameters (e.g. via CRAC_CRIU_OPTS) may be indeed useful. Passing down unified logging settings is an interesting idea, although it won't be able to supply arbitrary options. But agree, two different ways to provide options to the engine is too much. CRAC_CRIU_OPTS from one hand is criuengine specific, but it allows easy concatenation with previously set options

CRAC_CRIU_OPTS="$CRAC_CRIU_OPTIONS"


Implementing the same with VM options is possible, but will take some effort. Have we considered introducing `CREngineArg` of `ccstrlist` type (accumulated by existing VM parsing implementation)? So for example `-XX:CREngineArg=debug` would a) accumulate with previously set arguments; b) will cover not only criuengine.

BTW, CREngine is not strictly `diagnostic` ("options are not meant for VM tuning or for product modes."). The wast majority of VM options are "expert" ones.

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1879002234

From kyukihiro at openjdk.org  Mon Jan  8 06:57:46 2024
From: kyukihiro at openjdk.org (Kimura Yukihiro)
Date: Mon, 8 Jan 2024 06:57:46 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <U3MrzgkUMpknKRvgzVZ2MCoUWglo_cvJcNr7df-S01Y=.9eca2712-8c87-43c9-8f1a-f0b194aa3e81@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

Thank you for your comment. 
I will consider it further based on your feedback.

Thank you,
Kimura Yukihiro

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1880467761

From rvansa at openjdk.org  Mon Jan  8 09:15:14 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 8 Jan 2024 09:15:14 GMT
Subject: [crac] RFR: Add debug flag to -XX:CREngine.
In-Reply-To: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
References: <12wIGmSHSu_oP0NMgLhUEUdcSZtLL-8UKuoHNzybv0Y=.cc60f8c5-34ee-41fc-aa93-30912a5c10ec@github.com>
Message-ID: <0Ey-3dGwaExKG-ZUlJo_7f2WEZhl4zIIbHOECpyIAH4=.54adab29-76ee-4f14-bab8-de0ae52fdfb0@github.com>

On Sun, 24 Dec 2023 23:45:29 GMT, Kimura Yukihiro <kyukihiro at openjdk.org> wrote:

> Hello everyone,
> 
> This is my first PR for the CRAC project. I propose three modifications to the criuengine.
> 
> Firstly, I suggest adding a debug flag to the criuengine, as some JDK C/C++ native codes have the debug flag. 
> My proposal is to pass the debug flag using "-XX:CREngine=criuengine,debug,true".
> 
> Secondly, the criuengine has a useful function, print_command_args_to_stderr(), which prints the criu command line. 
> However, it is only called when an error occurs. I believe it would be beneficial if the criu command line is printed when the debug flag is specified.
> 
> The criu command line is built from the parameter of -XX:CREngine and environment variables such as CRAC_CRIU_PATH and CRAC_CRIU_OPT. 
> It would be helpful to see how it is actually assembled.
> 
> For example:
>  $ export CRAC_CRIU_PATH=/work/criu-crac-release-1.4/sbin/criu
>  $ ./jdk/bin/java -XX:CREngine=/work/jdk/lib/criuengine,-v,3,-o,output3.log,-d,true -XX:CRaCCheckpointTo=cr Test
> 
>  Command: /work/criu-crac-release-1.4/sbin/criu dump -t 3232214 -D cr --shell-job '--verbosity=3' -o output3.log
> 
> Thirdly, I propose that the criuengine command line, which is executed by the JavaVM, be printed when "-XX:CREngine=criuengine,debug,true" is specified. 
> For example, 
>  CRaC info executing: /work/jdk/lib/criuengine checkpoint -v 3 -o output3.log -d true cr
> 
> Testing:
> I have verified the jdk/crac/VMOptionsTest.java, which is a test for -XX:CREngine. I believe it's unnecessary to add a test for the debug flag to it.
> 
> Could you please review these modifications?
> 
> Thank you,
> Kimura Yukihiro

I meant diagnostic in the current state where all you can do is change output verbosity/destination. Had you added e.g. `--no-mmap-page-image` it would become more (and logging aside, this is really the only CRIU option that makes sense to change).

@yukikimmura I hope you're not offended by questioning the usefulness of your contribution; I simply feel that I made a mistake adding the CREngine params and therefore I am reluctant to build on top of that when I'd prefer to implement verbose logging in a different way.

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

PR Comment: https://git.openjdk.org/crac/pull/151#issuecomment-1880619254

From duke at openjdk.org  Wed Jan 31 16:29:42 2024
From: duke at openjdk.org (duke)
Date: Wed, 31 Jan 2024 16:29:42 GMT
Subject: [crac] Withdrawn: Stop JMX RMI before checkpoint & restart after
 restore
In-Reply-To: <2Ja1lzDT5dad5ZkTMj6sMTEaPGdOzh-GvFM8xHnnVFE=.5b2f01af-cdf4-4ae7-a1fa-961f22e1e3ac@github.com>
References: <2Ja1lzDT5dad5ZkTMj6sMTEaPGdOzh-GvFM8xHnnVFE=.5b2f01af-cdf4-4ae7-a1fa-961f22e1e3ac@github.com>
Message-ID: <GrQBNi4PncoaK5pj1OKf1mbScBPWpAA--6JlCrsZAzM=.2a23ae03-83ec-43b0-b29c-15ab0faeb88d@github.com>

On Wed, 6 Dec 2023 11:10:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> When JMX is exposed over RMI through system properties `com.sun.management.jmxremote.*` the checkpoint would fail; this PR closes all sockets and reopens listening sockets after restore.

This pull request has been closed without being integrated.

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

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