From duke at openjdk.org  Thu Mar  7 17:48:16 2024
From: duke at openjdk.org (duke)
Date: Thu, 7 Mar 2024 17:48:16 GMT
Subject: [crac] Withdrawn: Simplify CPUFeatures code
In-Reply-To: <RiMjp_2Y2SOvPOBUC9QgV6QtWyAQdkuVTaBqKlE5UgA=.aef8c69a-455e-4898-9aac-6135f372970d@github.com>
References: <RiMjp_2Y2SOvPOBUC9QgV6QtWyAQdkuVTaBqKlE5UgA=.aef8c69a-455e-4898-9aac-6135f372970d@github.com>
Message-ID: <Bl4g1fwZXJqFGqQnoUOvpk4tpxyr_C1_n_HH2UvfBIM=.685f4bd8-0fc8-4e75-94da-faa9c8fb8962@github.com>

On Sat, 16 Sep 2023 15:41:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> There is no functionality change. I guess the new code should be more simple and shorter. It was originally suggested by @AntonKozlov to use more functions than macros.
> 
> 
>  1 file changed, 44 insertions(+), 82 deletions(-)
>  ```
> So I find it clearly an improvement.
> The readable sub-commit is: https://github.com/openjdk/crac/pull/112/commits/6d9cb72b7a838dd4c9f107c5b71c4275005a0c23
> Otherwise it gets messed up by the other commit just renaming things.
> As an explanation: Original code had two lists of the same CPU features. An `EXCESSIVE` list and an `GLIBC_DISABLE` list. The had to be kept in sync (their sets being equal) which was sanity checked:
> 
>     if (PASTE_TOKENS(disable_handled_, kind) != PASTE_TOKENS(excessive_handled_, kind))                                                  \
> 
> So now there is the list just once (`EXCESSIVE`, the `GLIBC_DISABLE` one has been deleted). It looks stupid but when coding it I did not see it.
> Coding both variants of #136 was needlessly more difficult without this pull request applied and now I have to rebase this pull request.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Mar 15 13:51:04 2024
From: duke at openjdk.org (duke)
Date: Fri, 15 Mar 2024 13:51:04 GMT
Subject: [crac] Withdrawn: Ignore errors parsing classpath
In-Reply-To: <5nhvtHx-YLeBinFImB_lglwEfduOtrLjsqhP6s9MR30=.4fd8da56-c933-4462-adc1-32e20487abf8@github.com>
References: <5nhvtHx-YLeBinFImB_lglwEfduOtrLjsqhP6s9MR30=.4fd8da56-c933-4462-adc1-32e20487abf8@github.com>
Message-ID: <qcL2h85loFk-dyaXoa3BwCZgMf2QTu0c7zjePIIyuTg=.723ce3ba-98fb-4f4b-8c50-c429b7b47165@github.com>

On Fri, 15 Dec 2023 09:45:49 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This test is relevant mostly on Windows - trying to use URI in the form of `file:/C:/path/to/...` as classpath element. On Linux, this is parsed as two items as `File.pathSeparator` is `:`. However on Windows the second colon triggers an exception.

This pull request has been closed without being integrated.

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

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

From rvansa at openjdk.org  Mon Mar 18 07:38:38 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 18 Mar 2024 07:38:38 GMT
Subject: [crac] RFR: Improve C/R exception printout [v2]
In-Reply-To: <Nzb7YNH6ynpDVzBzfKdnAj2uT0anr5UcS1GsurX42cU=.095936d2-30a3-44bd-8389-d04c71d6feab@github.com>
References: <nRb4aqztsreUMQR_ebMEHXFI-jfka_GbjibPjmwJ_GA=.2d4f1d3d-08dc-4d63-a08e-744747b107fb@github.com>
 <Nzb7YNH6ynpDVzBzfKdnAj2uT0anr5UcS1GsurX42cU=.095936d2-30a3-44bd-8389-d04c71d6feab@github.com>
Message-ID: <bZ-ub4osWnvOxLwOOHVD5_9gDGEquG-lnymJC19PHak=.95d68720-8bb1-458e-8aaf-410f43434e8f@github.com>

On Fri, 16 Feb 2024 17:01: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)
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace suppressed exceptions with nested ones

Still relevant.

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

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

From simonis at openjdk.org  Mon Mar 18 11:04:15 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 18 Mar 2024 11:04:15 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem
Message-ID: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>

CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.

The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

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

Commit messages:
 - 8328344: [CRaC] Avoid error when running with -XX:+PerfDisableSharedMem

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

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

From rvansa at openjdk.org  Mon Mar 18 11:04:15 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 18 Mar 2024 11:04:15 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <C1bODeKyHi0AR3F3z_vP4uOzB06drrRsyS5AHZzIAwc=.53fe32c1-767b-40e5-9417-4cd5ac2a780d@github.com>

On Mon, 18 Mar 2024 10:37:04 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

Thanks, do you think we should have a test for the flag?

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

PR Comment: https://git.openjdk.org/crac/pull/153#issuecomment-2003572864

From simonis at openjdk.org  Tue Mar 19 10:02:06 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Mar 2024 10:02:06 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v2]
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Added test for -XX:+/-PerfDisableSharedMem

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

Changes:
  - all: https://git.openjdk.org/crac/pull/153/files
  - new: https://git.openjdk.org/crac/pull/153/files/5385fe90..78c171fe

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

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

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

From simonis at openjdk.org  Tue Mar 19 10:02:06 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Mar 2024 10:02:06 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <LG6VZZsKUHZZTZN9WJSmDnDj2V_PWpYixFbBmS3MRkI=.3e25327c-67ed-4089-82c1-9525273f775c@github.com>

On Mon, 18 Mar 2024 10:37:04 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

I've now added a test for `-XX:+/-PerfDisableSharedMem`, i.e. I've extended `PerfMemoryRestoreTest` to run with both, `-XX:-PerfDisableSharedMem` and `-XX:+PerfDisableSharedMem`.

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

PR Comment: https://git.openjdk.org/crac/pull/153#issuecomment-2006601529

From rvansa at openjdk.org  Tue Mar 19 15:16:36 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 19 Mar 2024 15:16:36 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v2]
In-Reply-To: <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>
Message-ID: <f6hqH0KjQACCYJ9cX0XmTJnbfnrPR6VY4UqrP61hQ1I=.bb02cbdd-6a3b-40d4-9652-7b3ce24a4e2e@github.com>

On Tue, 19 Mar 2024 10:02:06 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
>> 
>> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test for -XX:+/-PerfDisableSharedMem

test/jdk/jdk/crac/PerfMemoryRestoreTest.java line 69:

> 67:         while (!perfdata.toFile().exists()) {
> 68:             if (System.nanoTime() - start > TimeUnit.SECONDS.toNanos(10)) {
> 69:                 if (perfDisableSharedMem) {

The file won't ever appear, so this would busy loop for the whole 10 seconds, extending the testsuite. Could you avoid the loop completely, or in case of `perfDisableSharedMem == true` reduce the delay to, say, 100 ms?

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1530589986

From simonis at openjdk.org  Tue Mar 19 19:41:47 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Mar 2024 19:41:47 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v2]
In-Reply-To: <f6hqH0KjQACCYJ9cX0XmTJnbfnrPR6VY4UqrP61hQ1I=.bb02cbdd-6a3b-40d4-9652-7b3ce24a4e2e@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>
 <f6hqH0KjQACCYJ9cX0XmTJnbfnrPR6VY4UqrP61hQ1I=.bb02cbdd-6a3b-40d4-9652-7b3ce24a4e2e@github.com>
Message-ID: <coeRmka3niu54q_Rqz3oXBpQo9z2fLHuKeeV5o3mpX4=.b0ad65f3-f274-4e08-abf6-52b038dd6865@github.com>

On Tue, 19 Mar 2024 15:14:07 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test for -XX:+/-PerfDisableSharedMem
>
> test/jdk/jdk/crac/PerfMemoryRestoreTest.java line 69:
> 
>> 67:         while (!perfdata.toFile().exists()) {
>> 68:             if (System.nanoTime() - start > TimeUnit.SECONDS.toNanos(10)) {
>> 69:                 if (perfDisableSharedMem) {
> 
> The file won't ever appear, so this would busy loop for the whole 10 seconds, extending the testsuite. Could you avoid the loop completely, or in case of `perfDisableSharedMem == true` reduce the delay to, say, 100 ms?

If we expect that the file will appear we give it up to ten seconds to appear. If we want to be sure that it doesn't appear, we should then wait at least as long, right? Now for the positive case we expect that the file will appear quickly, so sleeping for a small amount of time like 10ms is fine. For the negative case, we already know that we will have to wait for the full ten seconds anyway, so we can just do that and not loop at all by sleeping 10 seconds.

I'll change the sleep time accordingly.

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1530978466

From simonis at openjdk.org  Tue Mar 19 19:53:01 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Mar 2024 19:53:01 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v3]
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <cFmJuLb0UcdxdEoAkTGNgx4zXpzUvj87JA42gSpTMgo=.46ab1dd3-8654-4a3a-ac79-9b3c2a273b9b@github.com>

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Don't busy wait for the appearance of the hs_perf file if running with -XX:+PerfDisableSharedMem

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

Changes:
  - all: https://git.openjdk.org/crac/pull/153/files
  - new: https://git.openjdk.org/crac/pull/153/files/78c171fe..43494834

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

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

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

From rvansa at openjdk.org  Wed Mar 20 08:05:33 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 20 Mar 2024 08:05:33 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v2]
In-Reply-To: <coeRmka3niu54q_Rqz3oXBpQo9z2fLHuKeeV5o3mpX4=.b0ad65f3-f274-4e08-abf6-52b038dd6865@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>
 <f6hqH0KjQACCYJ9cX0XmTJnbfnrPR6VY4UqrP61hQ1I=.bb02cbdd-6a3b-40d4-9652-7b3ce24a4e2e@github.com>
 <coeRmka3niu54q_Rqz3oXBpQo9z2fLHuKeeV5o3mpX4=.b0ad65f3-f274-4e08-abf6-52b038dd6865@github.com>
Message-ID: <twYM6Ze29IZYlsMfB2NPyNxRWVdEldyXMlKAXtXtyZY=.09c7ad85-beae-4542-bc31-84f99d08a67a@github.com>

On Tue, 19 Mar 2024 19:39:10 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> test/jdk/jdk/crac/PerfMemoryRestoreTest.java line 69:
>> 
>>> 67:         while (!perfdata.toFile().exists()) {
>>> 68:             if (System.nanoTime() - start > TimeUnit.SECONDS.toNanos(10)) {
>>> 69:                 if (perfDisableSharedMem) {
>> 
>> The file won't ever appear, so this would busy loop for the whole 10 seconds, extending the testsuite. Could you avoid the loop completely, or in case of `perfDisableSharedMem == true` reduce the delay to, say, 100 ms?
>
> If we expect that the file will appear we give it up to ten seconds to appear. If we want to be sure that it doesn't appear, we should then wait at least as long, right? Now for the positive case we expect that the file will appear quickly, so sleeping for a small amount of time like 10ms is fine. For the negative case, we already know that we will have to wait for the full ten seconds anyway, so we can just do that and not loop at all by sleeping 10 seconds.
> 
> I'll change the sleep time accordingly.

As you say, in normal case the file should appear very quickly. The 10 second duration is there only to avoid false positives. Yes, if you want to assert that the file does not appear you would have to wait much longer than what is the 'expected' time.

I hope you don't take this as too much nitpicking; I am trying to balance the duration of the testsuite (esp. for manual runs) - not only in this case but also setting a precedent in style - vs. the risk of false negatives. I hate false positives as these reduce the credibility of the testsuite, but in my view asserting the non-existence of the file is not important to justify stalling of tests - I expect that if the VM option is completely ignored the tests should blow somewhere else.

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1531642454

From simonis at openjdk.org  Wed Mar 20 10:05:45 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 20 Mar 2024 10:05:45 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v2]
In-Reply-To: <twYM6Ze29IZYlsMfB2NPyNxRWVdEldyXMlKAXtXtyZY=.09c7ad85-beae-4542-bc31-84f99d08a67a@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <uYWzqSmBInOKkzS72dQreTq2MQyRSWX62QgzzxpdcC8=.cd5c799c-10bc-4f84-a443-2a8866cbcb0c@github.com>
 <f6hqH0KjQACCYJ9cX0XmTJnbfnrPR6VY4UqrP61hQ1I=.bb02cbdd-6a3b-40d4-9652-7b3ce24a4e2e@github.com>
 <coeRmka3niu54q_Rqz3oXBpQo9z2fLHuKeeV5o3mpX4=.b0ad65f3-f274-4e08-abf6-52b038dd6865@github.com>
 <twYM6Ze29IZYlsMfB2NPyNxRWVdEldyXMlKAXtXtyZY=.09c7ad85-beae-4542-bc31-84f99d08a67a@github.com>
Message-ID: <AE4arAPpLa0GpR8JCmEhNYJo5bEUH7HSohzuwpya2-s=.0881937e-21ee-4dd3-b71b-1170fe2629fa@github.com>

On Wed, 20 Mar 2024 08:02:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> If we expect that the file will appear we give it up to ten seconds to appear. If we want to be sure that it doesn't appear, we should then wait at least as long, right? Now for the positive case we expect that the file will appear quickly, so sleeping for a small amount of time like 10ms is fine. For the negative case, we already know that we will have to wait for the full ten seconds anyway, so we can just do that and not loop at all by sleeping 10 seconds.
>> 
>> I'll change the sleep time accordingly.
>
> As you say, in normal case the file should appear very quickly. The 10 second duration is there only to avoid false positives. Yes, if you want to assert that the file does not appear you would have to wait much longer than what is the 'expected' time.
> 
> I hope you don't take this as too much nitpicking; I am trying to balance the duration of the testsuite (esp. for manual runs) - not only in this case but also setting a precedent in style - vs. the risk of false negatives. I hate false positives as these reduce the credibility of the testsuite, but in my view asserting the non-existence of the file is not important to justify stalling of tests - I expect that if the VM option is completely ignored the tests should blow somewhere else.

Please feel free to take this PR and modify it however you think. Unfortunately I won't have bandwidth to work on it in the next time.

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1531799493

From simonis at openjdk.org  Fri Mar 22 13:59:54 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 22 Mar 2024 13:59:54 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v4]
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <JtMZpP24H1IPYlYfEKTdwd3cfqZ6xAqFRv2sL8mmTEQ=.14ced3d8-29ee-4eb5-9a9e-9d6b0d82487c@github.com>

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Don't wait 2x10 seconds when with -XX:+PerfDisableSharedMem

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

Changes:
  - all: https://git.openjdk.org/crac/pull/153/files
  - new: https://git.openjdk.org/crac/pull/153/files/43494834..edee8cc0

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

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

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

From rvansa at openjdk.org  Fri Mar 22 13:59:55 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 22 Mar 2024 13:59:55 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v3]
In-Reply-To: <cFmJuLb0UcdxdEoAkTGNgx4zXpzUvj87JA42gSpTMgo=.46ab1dd3-8654-4a3a-ac79-9b3c2a273b9b@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <cFmJuLb0UcdxdEoAkTGNgx4zXpzUvj87JA42gSpTMgo=.46ab1dd3-8654-4a3a-ac79-9b3c2a273b9b@github.com>
Message-ID: <ZMrnw_NlYbQqk_FAcJmxeXtvxpMz69pbc_VPZqDy3BI=.d22e9285-7fdc-46bd-b346-db702f3b8ead@github.com>

On Tue, 19 Mar 2024 19:53:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
>> 
>> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't busy wait for the appearance of the hs_perf file if running with -XX:+PerfDisableSharedMem

@AntonKozlov I've replaced the 2x 10 second wait with 2x 100 ms - could you review please to give it a third pair of eyes?

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

PR Comment: https://git.openjdk.org/crac/pull/153#issuecomment-2015163565

From akozlov at openjdk.org  Fri Mar 22 16:47:35 2024
From: akozlov at openjdk.org (Anton Kozlov)
Date: Fri, 22 Mar 2024 16:47:35 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v4]
In-Reply-To: <JtMZpP24H1IPYlYfEKTdwd3cfqZ6xAqFRv2sL8mmTEQ=.14ced3d8-29ee-4eb5-9a9e-9d6b0d82487c@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <JtMZpP24H1IPYlYfEKTdwd3cfqZ6xAqFRv2sL8mmTEQ=.14ced3d8-29ee-4eb5-9a9e-9d6b0d82487c@github.com>
Message-ID: <ItYiHq95rcaFIVjrzUYCUrrCCVjr2pHQ0Es5PxIpdYU=.33cf1607-8da7-4bfc-891e-86bc76e7c2fe@github.com>

On Fri, 22 Mar 2024 13:59:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
>> 
>> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't wait 2x10 seconds when with -XX:+PerfDisableSharedMem

test/jdk/jdk/crac/PerfMemoryRestoreTest.java line 68:

> 66:         Path perfdata = Path.of("/tmp", "hsperfdata_" + System.getProperty("user.name"), pid);
> 67:         if (perfDisableSharedMem) {
> 68:             Thread.sleep(100);

I like the refactoring and that we can control this delay independently. 

Nit-picking: should not be this a named constant? And does 100ms has any reason behind, or can it be 1sec (a little bit safer)?

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1535880319

From simonis at openjdk.org  Tue Mar 26 08:04:02 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 26 Mar 2024 08:04:02 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v5]
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <a5MzzLZmaWSI1NMVtAHiJVVTSI9yErnp0EIQJPOog2Y=.5df881f6-ff72-4a78-90eb-65cf823c55c9@github.com>

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Extract delay to constant

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

Changes:
  - all: https://git.openjdk.org/crac/pull/153/files
  - new: https://git.openjdk.org/crac/pull/153/files/edee8cc0..19dd2d0c

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

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

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

From rvansa at openjdk.org  Tue Mar 26 08:04:02 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 26 Mar 2024 08:04:02 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v4]
In-Reply-To: <ItYiHq95rcaFIVjrzUYCUrrCCVjr2pHQ0Es5PxIpdYU=.33cf1607-8da7-4bfc-891e-86bc76e7c2fe@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <JtMZpP24H1IPYlYfEKTdwd3cfqZ6xAqFRv2sL8mmTEQ=.14ced3d8-29ee-4eb5-9a9e-9d6b0d82487c@github.com>
 <ItYiHq95rcaFIVjrzUYCUrrCCVjr2pHQ0Es5PxIpdYU=.33cf1607-8da7-4bfc-891e-86bc76e7c2fe@github.com>
Message-ID: <NWaa9Cs27-Vi6AChC5UkysoLtrCK4-flhif1LomHXmQ=.97f1b3bf-725d-4034-85e8-810b0e95781a@github.com>

On Fri, 22 Mar 2024 16:45:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't wait 2x10 seconds when with -XX:+PerfDisableSharedMem
>
> test/jdk/jdk/crac/PerfMemoryRestoreTest.java line 68:
> 
>> 66:         Path perfdata = Path.of("/tmp", "hsperfdata_" + System.getProperty("user.name"), pid);
>> 67:         if (perfDisableSharedMem) {
>> 68:             Thread.sleep(100);
> 
> I like the refactoring and that we can control this delay independently. 
> 
> Nit-picking: should not be this a named constant? And does 100ms has any reason behind, or can it be 1sec (a little bit safer)?

Extracted to constant.

My expert opinion says that the almost arbitrary choice of 100 ms is super good enough.

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

PR Review Comment: https://git.openjdk.org/crac/pull/153#discussion_r1538737997

From rvansa at openjdk.org  Tue Mar 26 16:08:38 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 26 Mar 2024 16:08:38 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v5]
In-Reply-To: <2i-sgzbKFF7PDRW4_LAJsYGG1dlEZNPtHTDT28pDkBQ=.5dc6b33d-375e-4c61-b497-7e9c8318d7fd@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
 <2i-sgzbKFF7PDRW4_LAJsYGG1dlEZNPtHTDT28pDkBQ=.5dc6b33d-375e-4c61-b497-7e9c8318d7fd@github.com>
Message-ID: <td_HxgAMGBYgDykE5DOBVti7lAtKHGeiEhmCOSnB9mE=.851fdcc6-e61e-44ca-be3f-d87a03491fcc@github.com>

On Tue, 31 Oct 2023 00:13:23 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
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix github compilation signedness problem

Sorry for keeping this waiting for a long time. In the past I wasn't sure about using `/tmp/` rather than `shm_open` target but since `os::get_temp_directory()` has this part hard-coded, too, I think it's acceptable to use that one.

I would prefer `crac_restore_finalize` to use an enum rather than a `char` but otherwise this looks good - and if it fixes some usecase, let's integrate it.

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/134#pullrequestreview-1960922290

From akozlov at openjdk.org  Tue Mar 26 20:50:36 2024
From: akozlov at openjdk.org (Anton Kozlov)
Date: Tue, 26 Mar 2024 20:50:36 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v5]
In-Reply-To: <a5MzzLZmaWSI1NMVtAHiJVVTSI9yErnp0EIQJPOog2Y=.5df881f6-ff72-4a78-90eb-65cf823c55c9@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <a5MzzLZmaWSI1NMVtAHiJVVTSI9yErnp0EIQJPOog2Y=.5df881f6-ff72-4a78-90eb-65cf823c55c9@github.com>
Message-ID: <utltO86X6nn6UkBfq1Gi4lRI2Yy6s9tLnO-Ea11d0rc=.a028332e-fa5f-43ca-bf2b-83b923eb1d9c@github.com>

On Tue, 26 Mar 2024 08:04:02 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
>> 
>> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract delay to constant

Thanks, LGTM

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

Marked as reviewed by akozlov (Lead).

PR Review: https://git.openjdk.org/crac/pull/153#pullrequestreview-1961701541

From jkratochvil at openjdk.org  Wed Mar 27 08:36:41 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 27 Mar 2024 08:36:41 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v5]
In-Reply-To: <td_HxgAMGBYgDykE5DOBVti7lAtKHGeiEhmCOSnB9mE=.851fdcc6-e61e-44ca-be3f-d87a03491fcc@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
 <2i-sgzbKFF7PDRW4_LAJsYGG1dlEZNPtHTDT28pDkBQ=.5dc6b33d-375e-4c61-b497-7e9c8318d7fd@github.com>
 <td_HxgAMGBYgDykE5DOBVti7lAtKHGeiEhmCOSnB9mE=.851fdcc6-e61e-44ca-be3f-d87a03491fcc@github.com>
Message-ID: <HVKj5Hm7b1KcViOvzqLyFs4GIThiHirYoyBW3cqwpnA=.5fdec443-6a26-47e5-8fc2-820f74630960@github.com>

On Tue, 26 Mar 2024 16:05:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix github compilation signedness problem
>
> Sorry for keeping this waiting for a long time. In the past I wasn't sure about using `/tmp/` rather than `shm_open` target but since `os::get_temp_directory()` has this part hard-coded, too, I think it's acceptable to use that one.
> 
> I would prefer `crac_restore_finalize` to use an enum rather than a `char` but otherwise this looks good - and if it fixes some usecase, let's integrate it.

@rvansa Sorry for the review but we have been last week talking with @AntonKozlov I should rather do the full rework (move the CPUFeatures protection to the parent JDK before the JDK is restored) than this fix-up.

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

PR Comment: https://git.openjdk.org/crac/pull/134#issuecomment-2022205320

From jkratochvil at openjdk.org  Wed Mar 27 08:39:01 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 27 Mar 2024 08:39:01 GMT
Subject: [crac] RFR: GLIBC->CPU flags optimization [v2]
In-Reply-To: <79KPYS3M1hDTFo1DDXbeQGxUi6ohmFNfy4NXFK9AlxI=.3034a50f-ce19-4dcc-a524-5361dd30dbc7@github.com>
References: <79KPYS3M1hDTFo1DDXbeQGxUi6ohmFNfy4NXFK9AlxI=.3034a50f-ce19-4dcc-a524-5361dd30dbc7@github.com>
Message-ID: <oqPlPAJvulYPZU-4Ee1YFv2SRVkCnQV2jJjMUFE097c=.aec894c2-90c4-4da0-b192-92172d0ec1eb@github.com>

> Reduce the number of `GLIBC_*` flags when it can use existing `CPU_*` flags.
> This patch was split out of PR #136.
> 
> 
>  2 files changed, 9 insertions(+), 17 deletions(-)
> 
> So I find it clearly an improvement.
> As an explanation: I created the GLIBC_* namespace in addition to the existing upstream CPU_* namespace. And some my additions in GLIBC_* namespace have now appeared by https://github.com/openjdk/jdk/commit/d50b6eb342e9ec96d1a01dafc317e00725dc84c0 also in the upstream CPU_* namespace. They were missing in the CPU_* namespace when I was implementing it. So we can remove the duplicity from GLIBC_* namespace.

Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'crac' into crac-glibccpureduction
 - GLIBC->CPU flags optimization

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

Changes:
  - all: https://git.openjdk.org/crac/pull/139/files
  - new: https://git.openjdk.org/crac/pull/139/files/5f77d82b..f6b372e2

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

  Stats: 277 lines in 15 files changed: 190 ins; 31 del; 56 mod
  Patch: https://git.openjdk.org/crac/pull/139.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/139/head:pull/139

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

From rvansa at openjdk.org  Wed Mar 27 08:47:50 2024
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 27 Mar 2024 08:47:50 GMT
Subject: [crac] RFR: GLIBC->CPU flags optimization [v2]
In-Reply-To: <oqPlPAJvulYPZU-4Ee1YFv2SRVkCnQV2jJjMUFE097c=.aec894c2-90c4-4da0-b192-92172d0ec1eb@github.com>
References: <79KPYS3M1hDTFo1DDXbeQGxUi6ohmFNfy4NXFK9AlxI=.3034a50f-ce19-4dcc-a524-5361dd30dbc7@github.com>
 <oqPlPAJvulYPZU-4Ee1YFv2SRVkCnQV2jJjMUFE097c=.aec894c2-90c4-4da0-b192-92172d0ec1eb@github.com>
Message-ID: <Ge2fD5-lmuUsABiqF6tfnJCGGz52djpUpYk_46GLEok=.b61dcb95-dcea-4934-bf73-7279bce1ed81@github.com>

On Wed, 27 Mar 2024 08:39:01 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Reduce the number of `GLIBC_*` flags when it can use existing `CPU_*` flags.
>> This patch was split out of PR #136.
>> 
>> 
>>  2 files changed, 9 insertions(+), 17 deletions(-)
>> 
>> So I find it clearly an improvement.
>> As an explanation: I created the GLIBC_* namespace in addition to the existing upstream CPU_* namespace. And some my additions in GLIBC_* namespace have now appeared by https://github.com/openjdk/jdk/commit/d50b6eb342e9ec96d1a01dafc317e00725dc84c0 also in the upstream CPU_* namespace. They were missing in the CPU_* namespace when I was implementing it. So we can remove the duplicity from GLIBC_* namespace.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'crac' into crac-glibccpureduction
>  - GLIBC->CPU flags optimization

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/139#pullrequestreview-1962650373

From jkratochvil at openjdk.org  Thu Mar 28 09:51:48 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 28 Mar 2024 09:51:48 GMT
Subject: [crac] Integrated: GLIBC->CPU flags optimization
In-Reply-To: <79KPYS3M1hDTFo1DDXbeQGxUi6ohmFNfy4NXFK9AlxI=.3034a50f-ce19-4dcc-a524-5361dd30dbc7@github.com>
References: <79KPYS3M1hDTFo1DDXbeQGxUi6ohmFNfy4NXFK9AlxI=.3034a50f-ce19-4dcc-a524-5361dd30dbc7@github.com>
Message-ID: <YfoV5FkmgQjR4lbYycxvb0RVoTGSnSrj96YKkMpIKQM=.105e3f1e-37c9-4aa0-a206-3b7fd63ba0f1@github.com>

On Fri, 10 Nov 2023 10:34:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Reduce the number of `GLIBC_*` flags when it can use existing `CPU_*` flags.
> This patch was split out of PR #136.
> 
> 
>  2 files changed, 9 insertions(+), 17 deletions(-)
> 
> So I find it clearly an improvement.
> As an explanation: I created the GLIBC_* namespace in addition to the existing upstream CPU_* namespace. And some my additions in GLIBC_* namespace have now appeared by https://github.com/openjdk/jdk/commit/d50b6eb342e9ec96d1a01dafc317e00725dc84c0 also in the upstream CPU_* namespace. They were missing in the CPU_* namespace when I was implementing it. So we can remove the duplicity from GLIBC_* namespace.

This pull request has now been integrated.

Changeset: e5e4714d
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/e5e4714dc0781bb328985ec6f84bf96a0004f47f
Stats:     19 lines in 2 files changed: 2 ins; 10 del; 7 mod

GLIBC->CPU flags optimization

Reviewed-by: rvansa

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

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

From simonis at openjdk.org  Thu Mar 28 14:06:56 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 28 Mar 2024 14:06:56 GMT
Subject: [crac] RFR: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem [v3]
In-Reply-To: <ZMrnw_NlYbQqk_FAcJmxeXtvxpMz69pbc_VPZqDy3BI=.d22e9285-7fdc-46bd-b346-db702f3b8ead@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
 <cFmJuLb0UcdxdEoAkTGNgx4zXpzUvj87JA42gSpTMgo=.46ab1dd3-8654-4a3a-ac79-9b3c2a273b9b@github.com>
 <ZMrnw_NlYbQqk_FAcJmxeXtvxpMz69pbc_VPZqDy3BI=.d22e9285-7fdc-46bd-b346-db702f3b8ead@github.com>
Message-ID: <UCyzZkM3bwnGXaqsRtzQSIBLP5DCFyNrhvSyhogv6C4=.00f98cb3-18d8-46b9-b834-a1d785ab8fef@github.com>

On Fri, 22 Mar 2024 13:55:59 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't busy wait for the appearance of the hs_perf file if running with -XX:+PerfDisableSharedMem
>
> @AntonKozlov I've replaced the 2x 10 second wait with 2x 100 ms - could you review please to give it a third pair of eyes?

Thanks @rvansa, @AntonKozlov for finishing this issue! I'll integrate it.

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

PR Comment: https://git.openjdk.org/crac/pull/153#issuecomment-2025261846

From simonis at openjdk.org  Thu Mar 28 14:06:57 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 28 Mar 2024 14:06:57 GMT
Subject: [crac] Integrated: 8328344: [CRaC] Avoid error when running with
 -XX:+PerfDisableSharedMem
In-Reply-To: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
References: <6wmOiykYQZGjdegAdHs34l8NgoQbp6lu0MyzcSvof2k=.d5981682-42e7-49ee-b44d-2cf59a1b33af@github.com>
Message-ID: <-Ne35ZplvAM3WldtB7KT5hWMbGfgWIuQJWr_Euj0s90=.ce9ee04d-30ca-4fe0-b9f2-f7342c73eead@github.com>

On Mon, 18 Mar 2024 10:37:04 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> CRaC tries to unconditionally restore the hsperf file, even if the checkpointed JVM process was started with `-XX:+PerfDisableSharedMem`.
> 
> The fix is trivial: check for the existence of the hsperf file in `PerfMemoryLinux::restore()` just as we already do it in `PerfMemoryLinux::checkpoint()`.

This pull request has now been integrated.

Changeset: 7d03b259
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/7d03b259392fbfaa27d3223e80cfbfc5a5d833de
Stats:     60 lines in 2 files changed: 39 ins; 10 del; 11 mod

8328344: [CRaC] Avoid error when running with -XX:+PerfDisableSharedMem

Reviewed-by: akozlov

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

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

From duke at openjdk.org  Fri Mar 29 13:47:50 2024
From: duke at openjdk.org (duke)
Date: Fri, 29 Mar 2024 13:47:50 GMT
Subject: [crac] Withdrawn: 8314610: hotspot can't compile with the latest of
 gtest because of <iomanip>
In-Reply-To: <KuO46-3kEm-Q3_-rUmS0L6b-3vA7pDaj_JFbccDEGoI=.1d34426d-990e-44a2-98b1-654f80e6ab77@github.com>
References: <KuO46-3kEm-Q3_-rUmS0L6b-3vA7pDaj_JFbccDEGoI=.1d34426d-990e-44a2-98b1-654f80e6ab77@github.com>
Message-ID: <yPfLdmVzG6m8qLXkIIE3ASvAxzkdzWlOoVNBDBGnxV4=.b9b91a1c-f6a4-4b87-87f9-03704dabc015@github.com>

On Fri, 2 Feb 2024 07:52:57 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Although a better fix with be just a new merge with master.
> 
> 
> test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp: In member function 'virtual void gc_memset_with_concurrent_readers_Test::TestBody()':
> test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp:82:34: error: 'setw' is not a member of 'std' 
>    82 |                          << std::setw(2) << line_byte(lp, 0) << " "
>       |                                  ^~~~

This pull request has been closed without being integrated.

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

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