From jkratochvil at openjdk.org  Mon Oct  2 08:30:12 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Oct 2023 08:30:12 GMT
Subject: [crac] Integrated: Fix OSX x86_64 CRaC crash
In-Reply-To: <HmOpAXfg1HPX7Re-tCCHHRGPCAQ2BANDM_F7BlBjBq8=.116846bc-9ff9-4dc0-838f-d14ba4bd6ed8@github.com>
References: <HmOpAXfg1HPX7Re-tCCHHRGPCAQ2BANDM_F7BlBjBq8=.116846bc-9ff9-4dc0-838f-d14ba4bd6ed8@github.com>
Message-ID: <9ypPg-9t85bx0UkaqMTL5YWn_zbXlYQwcvCX9QXgT6g=.64f550c1-fd37-4058-9f41-2a41d3049fe8@github.com>

On Fri, 29 Sep 2023 10:12:50 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> - copy-paste the same code from src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
> 
> It has fixed 3 testcases but the last 4th failure looks to be unrelated to this problem.
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/jdk/crac/JarFileFactoryCacheTest/JarFileFactoryCacheTest.java
>                                                          1     1     0     0
>    jtreg:test/jdk/jdk/crac/MXBean.java                   1     1     0     0
>    jtreg:test/jdk/jdk/crac/RefQueueTest.java             1     1     0     0
>    jtreg:test/jdk/jdk/crac/recursiveCheckpoint/Test.java
>>>                                                       1     0     1     0 <<
> ==============================

This pull request has now been integrated.

Changeset: 4d1e7b9d
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/4d1e7b9d0bb8d399bb692ce477ac503f0bffe2ed
Stats:     10 lines in 2 files changed: 9 ins; 0 del; 1 mod

Fix OSX x86_64 CRaC crash

Reviewed-by: rvansa

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

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

From jkratochvil at openjdk.org  Mon Oct  2 14:56:01 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Oct 2023 14:56:01 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>

> CRaC: Fix fds opened for logging

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 eight additional commits since the last revision:

 - AsyncLogWriter: add stop() and resume()
 - Merge branch 'crac' into crac-logfd
 - b229ea41: <no commit message found>
 - 8f161825: <no commit message found>
 - d8a454cb: <no commit message found>
 - Merge branch 'crac' into crac-logfd
 - +testcase
 - CRaC: Fix fds opened for logging

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/17362702..39d38191

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

  Stats: 153 lines in 16 files changed: 133 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/crac/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/113/head:pull/113

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

From jkratochvil at openjdk.org  Mon Oct  2 14:56:03 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Oct 2023 14:56:03 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <Z8nxfIfRW8qNseuCk21HpX56gjdUM7uWuuoVTUUkRlE=.70036a03-57cf-4c39-953b-f8a7bd516409@github.com>

On Tue, 19 Sep 2023 14:30:15 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> CRaC: Fix fds opened for logging

I am not sure when to call those functions, whether in VM Thread or before...

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

PR Comment: https://git.openjdk.org/crac/pull/113#issuecomment-1734977560

From rvansa at openjdk.org  Mon Oct  2 14:56:04 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 14:56:04 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
Message-ID: <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>

On Mon, 2 Oct 2023 14:49:56 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> 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 eight additional commits since the last revision:
> 
>  - AsyncLogWriter: add stop() and resume()
>  - Merge branch 'crac' into crac-logfd
>  - b229ea41: <no commit message found>
>  - 8f161825: <no commit message found>
>  - d8a454cb: <no commit message found>
>  - Merge branch 'crac' into crac-logfd
>  - +testcase
>  - CRaC: Fix fds opened for logging

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

> 429:   Universe::heap()->finish_collection();
> 430: 
> 431:   AsyncLogWriter::instance()->flush();

As a non-java thread, AsyncLogWriter does not participate in the safepoint protocol. What happens if another non-java thread enqueues a message to be written while the output is closed?

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1337075009

From jkratochvil at openjdk.org  Mon Oct  2 14:56:04 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Oct 2023 14:56:04 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
 <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>
Message-ID: <O9AzZTKlOxkorSoi1jQsv2crQxhnpP6X__-rEtbPqsQ=.83304018-65b3-498d-a158-11dcc02e35cf@github.com>

On Tue, 26 Sep 2023 11:40:45 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - AsyncLogWriter: add stop() and resume()
>>  - Merge branch 'crac' into crac-logfd
>>  - b229ea41: <no commit message found>
>>  - 8f161825: <no commit message found>
>>  - d8a454cb: <no commit message found>
>>  - Merge branch 'crac' into crac-logfd
>>  - +testcase
>>  - CRaC: Fix fds opened for logging
>
> src/hotspot/share/runtime/crac.cpp line 431:
> 
>> 429:   Universe::heap()->finish_collection();
>> 430: 
>> 431:   AsyncLogWriter::instance()->flush();
> 
> As a non-java thread, AsyncLogWriter does not participate in the safepoint protocol. What happens if another non-java thread enqueues a message to be written while the output is closed?

OK, I have to improve it, thanks.

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1337256728

From jkratochvil at openjdk.org  Mon Oct  2 14:56:05 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 2 Oct 2023 14:56:05 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <O9AzZTKlOxkorSoi1jQsv2crQxhnpP6X__-rEtbPqsQ=.83304018-65b3-498d-a158-11dcc02e35cf@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
 <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>
 <O9AzZTKlOxkorSoi1jQsv2crQxhnpP6X__-rEtbPqsQ=.83304018-65b3-498d-a158-11dcc02e35cf@github.com>
Message-ID: <FUtyDwlasv0jyKuJuGPbUeJ6qGtP0tXwBkAoIYN2OFI=.f2b8a3f3-d70b-437a-bfa4-2bf68076dd49@github.com>

On Tue, 26 Sep 2023 13:56:50 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/runtime/crac.cpp line 431:
>> 
>>> 429:   Universe::heap()->finish_collection();
>>> 430: 
>>> 431:   AsyncLogWriter::instance()->flush();
>> 
>> As a non-java thread, AsyncLogWriter does not participate in the safepoint protocol. What happens if another non-java thread enqueues a message to be written while the output is closed?
>
> OK, I have to improve it, thanks.

I hope the stop() and resume() do fix it. But there is no testcase for that, do you want it?

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1342793215

From akozlov at openjdk.org  Mon Oct  2 17:55:12 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Mon, 2 Oct 2023 17:55:12 GMT
Subject: [crac] RFR: Close files opened by Decoder before checkpoint
In-Reply-To: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
References: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
Message-ID: <KvXANZoGvJ2x17BSsykt2UHCOwk2REyF3shFAr3h6Uc=.6104790d-7980-4039-9fcb-529a2f26bc5a@github.com>

On Mon, 25 Sep 2023 13:08:24 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Native memory tracking needs to resolve some addresses for stack unwinding and the decoders keep some shared library files open as a cache. Since the decoder instances can be re-allocated anytime this fix just destroys them before a checkpoint.

src/hotspot/share/utilities/decoder.cpp line 134:

> 132:     delete _error_handler_decoder;
> 133:     _error_handler_decoder = nullptr;
> 134:   }

Error handler appears only during fatal error reporting. We can drop the handling and syncing with the errorred thread, as fatal error will follow anyway after we find error handler. So this can be

guarantee(_error_handler_decoder == nullptr)

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

PR Review Comment: https://git.openjdk.org/crac/pull/116#discussion_r1342986789

From akozlov at openjdk.org  Mon Oct  2 17:57:29 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Mon, 2 Oct 2023 17:57:29 GMT
Subject: [crac] RFR: Drop perfdata and cppath
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <8dTVuXOkdCnAogpVI26448Yn8i7gC7ViG9N5e9qnnWg=.d3c681d8-19ef-4c68-a883-516aec32f6a4@github.com>

On Wed, 27 Sep 2023 20:40:53 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

> 64:             Thread.sleep(10);
> 65:         }
> 66:         // Note: we need to check the checkpoint.pid(), which should be restored (when using CRIU),

Could you also check that jcmd works after restore?

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

PR Review Comment: https://git.openjdk.org/crac/pull/119#discussion_r1342988896

From rvansa at openjdk.org  Mon Oct  2 18:37:12 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 18:37:12 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <FUtyDwlasv0jyKuJuGPbUeJ6qGtP0tXwBkAoIYN2OFI=.f2b8a3f3-d70b-437a-bfa4-2bf68076dd49@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
 <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>
 <O9AzZTKlOxkorSoi1jQsv2crQxhnpP6X__-rEtbPqsQ=.83304018-65b3-498d-a158-11dcc02e35cf@github.com>
 <FUtyDwlasv0jyKuJuGPbUeJ6qGtP0tXwBkAoIYN2OFI=.f2b8a3f3-d70b-437a-bfa4-2bf68076dd49@github.com>
Message-ID: <JCfLHA0_ythllgC6tQ1fLCRmBOaQpCe_G1D86GGAjHg=.39d97686-6e29-42e3-b82a-abde30250ef0@github.com>

On Mon, 2 Oct 2023 14:48:48 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> OK, I have to improve it, thanks.
>
> I hope the stop() and resume() do fix it. But there is no testcase for that, do you want it?

I guess that a testcase for the synchronization would be quite difficult to do, as you'd be trying to simulate a race.

However, I am not convinced the `stop()` and `resume()` work correctly: the log writer does not need to own the lock while writing messages to the (potentially nulled) outputs; you flush the buffer and then acquire the lock, effectively blocking all log producers from enqueuing further messages. However if someone enqueues a message right after flush, the log writer has a chance to dequeue it (actually swap queues) and even if you acquire lock then, continue writing these messages to the closed output.

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1343024529

From rvansa at openjdk.org  Mon Oct  2 18:59:40 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 18:59:40 GMT
Subject: [crac] RFR: Close files opened by Decoder before checkpoint [v2]
In-Reply-To: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
References: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
Message-ID: <6S30weJNZ0mIL0VExeOO1BQwq8xU9G5gZ_xiXM4mJ_E=.5e069f4b-789f-4fbf-a985-a13f270fd79a@github.com>

> Native memory tracking needs to resolve some addresses for stack unwinding and the decoders keep some shared library files open as a cache. Since the decoder instances can be re-allocated anytime this fix just destroys them before a checkpoint.

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

  Assume error handler decoder is null during checkpoint

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

Changes:
  - all: https://git.openjdk.org/crac/pull/116/files
  - new: https://git.openjdk.org/crac/pull/116/files/f2e99a2d..ee544fc8

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

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

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

From rvansa at openjdk.org  Mon Oct  2 18:59:41 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 18:59:41 GMT
Subject: [crac] RFR: Close files opened by Decoder before checkpoint
In-Reply-To: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
References: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
Message-ID: <SsKCMiOqweFe5aMfcL9hWoolEziZq0c3skNzBGlU5Cg=.b47950e9-cd6e-41ee-934f-e97b72034b07@github.com>

On Mon, 25 Sep 2023 13:08:24 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Native memory tracking needs to resolve some addresses for stack unwinding and the decoders keep some shared library files open as a cache. Since the decoder instances can be re-allocated anytime this fix just destroys them before a checkpoint.

Agreed, updated.

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

PR Comment: https://git.openjdk.org/crac/pull/116#issuecomment-1743577342

From rvansa at openjdk.org  Mon Oct  2 19:51:51 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 19:51:51 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v2]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <mng8ItVRx4E1Ai2amtUDW-Iz-jCOwSNWAmwkD3G8AXE=.14e19a19-4160-4786-8810-055a5c24124e@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Add jcmd <pid> PerfCounter.print to the test

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/71e54c25..bd6adcc8

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

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

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

From rvansa at openjdk.org  Mon Oct  2 19:51:53 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Oct 2023 19:51:53 GMT
Subject: [crac] RFR: Drop perfdata and cppath
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <SE2mUm7YfhhlUdL8SUSBwxupnmj6mmCLVD7En1qFfGc=.77e930f5-5d76-408e-ab68-4a2da6d7fa30@github.com>

On Wed, 27 Sep 2023 20:40:53 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

Added `jcmd <pid> PerfCounter.print` as requested.

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

PR Comment: https://git.openjdk.org/crac/pull/119#issuecomment-1743637518

From rvansa at openjdk.org  Tue Oct  3 07:11:55 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Oct 2023 07:11:55 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v2]
In-Reply-To: <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
Message-ID: <t83JjbFmAKzaeoJAPCJHO1evlLb_alsIDx5F39vV_kY=.085b7a72-62f4-4d41-a38f-84ba67feb676@github.com>

On Mon, 2 Oct 2023 14:56:01 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> 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 eight additional commits since the last revision:
> 
>  - AsyncLogWriter: add stop() and resume()
>  - Merge branch 'crac' into crac-logfd
>  - b229ea41: <no commit message found>
>  - 8f161825: <no commit message found>
>  - d8a454cb: <no commit message found>
>  - Merge branch 'crac' into crac-logfd
>  - +testcase
>  - CRaC: Fix fds opened for logging

About when to call them: IMO the more you do outside the VM thread the better. OpenJDK CRaC has gone the way where we perform most of the C/R handling in parallel with running the application, as opposed to the approach in OpenJ9 where even the Java callbacks (Resource.beforeCheckpoint/afterRestore) are performed in a single-threaded mode (which has its own advantage in a reduced need for complicated synchronization), so it is better to keep to philosophy consistent.

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

PR Comment: https://git.openjdk.org/crac/pull/113#issuecomment-1744311006

From rvansa at openjdk.org  Tue Oct  3 07:17:12 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Oct 2023 07:17:12 GMT
Subject: [crac] RFR: Persist memory in-JVM [v7]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <J7ndmKnlgVEEVO4-jWQtMo7HuycmErFguzd-x-lzRmM=.a4f0e33f-9221-4217-a2e6-26e59e388a35@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge remote-tracking branch 'origin/crac' into persist_memory
 - Fix reloading memory when checkpoint fails
 - Fix compilation on different OSes
 - Improve aarch64 assembly
 - Move MemoryPersister impl to own file
 - Merge branch 'crac' into persist_memory
 - Backport of API from future changes for other persistent memory features
 - Another assembly fix
 - Don't fork when we're not unregistering rseq
 - Fix assembly loop
 - ... and 27 more: https://git.openjdk.org/crac/compare/4d1e7b9d...fea0155a

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

Changes: https://git.openjdk.org/crac/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=95&range=06
  Stats: 1195 lines in 33 files changed: 1164 ins; 12 del; 19 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From rvansa at openjdk.org  Wed Oct  4 12:54:42 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Oct 2023 12:54:42 GMT
Subject: [crac] RFR: Persist memory in-JVM [v8]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <si44d9Hfekno9FBJbKEuAUPeuA3eqQaYQweHTNosS18=.8388c83a-4c6c-4e23-aae9-3a794efedaa4@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

Radim Vansa has updated the pull request incrementally with six additional commits since the last revision:

 - Fix x86 build
 - Use number of threads directly
 - Don't persist CodeCache used for non-nMethods
   
   The stubs allocated in this heap are used for atomic operations on
   aarch64, avoiding them before the memory is restored would be complicated.
 - Fix close() on windows
 - Add overrides (OSX build fix)
 - Fix recursiveCheckpoint

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

Changes:
  - all: https://git.openjdk.org/crac/pull/95/files
  - new: https://git.openjdk.org/crac/pull/95/files/fea0155a..78dfa7cb

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

  Stats: 203 lines in 9 files changed: 128 ins; 40 del; 35 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From jkratochvil at openjdk.org  Wed Oct  4 14:00:56 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 4 Oct 2023 14:00:56 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v3]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <h-EYi4LU4GSqlboIT9LSsdhunxUBv7XKDfAsyK5LUg0=.1bea9376-630f-4d94-bd98-36fc0647746d@github.com>

> CRaC: Fix fds opened for logging

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

  Fix a race by new _block_async.
   - bugreported by Radim Vansa

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/39d38191..a4666eb4

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

  Stats: 9 lines in 3 files changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/crac/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/113/head:pull/113

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

From jkratochvil at openjdk.org  Wed Oct  4 14:14:38 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 4 Oct 2023 14:14:38 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v4]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <huuf-xSR9F6f-ym1wtz8lTdqYaxC-RPCgpyDM_xGVQQ=.f1882456-8e00-4adb-aab4-5709d6161764@github.com>

> CRaC: Fix fds opened for logging

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

  Move log suspension out of VM thread.

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/a4666eb4..58fd093b

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

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

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

From rvansa at openjdk.org  Thu Oct  5 06:56:44 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Oct 2023 06:56:44 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v4]
In-Reply-To: <huuf-xSR9F6f-ym1wtz8lTdqYaxC-RPCgpyDM_xGVQQ=.f1882456-8e00-4adb-aab4-5709d6161764@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <huuf-xSR9F6f-ym1wtz8lTdqYaxC-RPCgpyDM_xGVQQ=.f1882456-8e00-4adb-aab4-5709d6161764@github.com>
Message-ID: <TZ3dBcf-XwQRSndmKXt1gByRZSS3nJo39nInnQJrVyw=.68e2ad53-b7e9-4328-a612-d0d0c840f7e2@github.com>

On Wed, 4 Oct 2023 14:14:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move log suspension out of VM thread.

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

> 437:   }
> 438:   if (cr.ok()) {
> 439:     LogConfiguration::reopen();

Looks like the log stays closed & blocked if the checkpoint fails?

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1346869978

From jkratochvil at openjdk.org  Thu Oct  5 07:31:30 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 07:31:30 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v5]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <cQD1s96fgUjielZxVpu_hUX5PrVFkOiEu0nQosUdOkc=.e109cfd8-660d-4250-b2cf-5211c9362dee@github.com>

> CRaC: Fix fds opened for logging

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

  Do not keep logs closed if snapshot failed
   - bugreported by Radim Vansa

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/58fd093b..b941490f

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

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

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

From jkratochvil at openjdk.org  Thu Oct  5 07:38:43 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 07:38:43 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v5]
In-Reply-To: <JCfLHA0_ythllgC6tQ1fLCRmBOaQpCe_G1D86GGAjHg=.39d97686-6e29-42e3-b82a-abde30250ef0@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <sJLfge-mny-05TOYGuc4uI3WO7SV-d5Qre_aGR_pSh8=.3d8a5034-5419-46cf-9768-0b4b17c13d30@github.com>
 <TUWOM6UL4AKAEbW7ELqeOwobIu9Rn05vkR8e7j82Bk8=.5647059e-4bc9-4964-a080-05c189037b02@github.com>
 <O9AzZTKlOxkorSoi1jQsv2crQxhnpP6X__-rEtbPqsQ=.83304018-65b3-498d-a158-11dcc02e35cf@github.com>
 <FUtyDwlasv0jyKuJuGPbUeJ6qGtP0tXwBkAoIYN2OFI=.f2b8a3f3-d70b-437a-bfa4-2bf68076dd49@github.com>
 <JCfLHA0_ythllgC6tQ1fLCRmBOaQpCe_G1D86GGAjHg=.39d97686-6e29-42e3-b82a-abde30250ef0@github.com>
Message-ID: <nWPg7ybzAjBOiUr8PdmVn3T6iTnl-AcAPBysEeA8TjQ=.f9c6fe4d-cd7d-4410-a7fe-a94234aa4328@github.com>

On Mon, 2 Oct 2023 18:34:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> I hope the stop() and resume() do fix it. But there is no testcase for that, do you want it?
>
> I guess that a testcase for the synchronization would be quite difficult to do, as you'd be trying to simulate a race.
> 
> However, I am not convinced the `stop()` and `resume()` work correctly: the log writer does not need to own the lock while writing messages to the (potentially nulled) outputs; you flush the buffer and then acquire the lock, effectively blocking all log producers from enqueuing further messages. However if someone enqueues a message right after flush, the log writer has a chance to dequeue it (actually swap queues) and even if you acquire lock then, continue writing these messages to the closed output.

Race reproducers are also a part of testsuites - [ptrace-testsuite](https://sourceware.org/systemtap/wiki/utrace/tests) limits their run by its `TESTTIME` parameter. I sure did not try how easily would be to reproduce this race and I am sure happy not to write such a testcase.

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1346938564

From jkratochvil at openjdk.org  Thu Oct  5 07:38:43 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 07:38:43 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v4]
In-Reply-To: <TZ3dBcf-XwQRSndmKXt1gByRZSS3nJo39nInnQJrVyw=.68e2ad53-b7e9-4328-a612-d0d0c840f7e2@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <huuf-xSR9F6f-ym1wtz8lTdqYaxC-RPCgpyDM_xGVQQ=.f1882456-8e00-4adb-aab4-5709d6161764@github.com>
 <TZ3dBcf-XwQRSndmKXt1gByRZSS3nJo39nInnQJrVyw=.68e2ad53-b7e9-4328-a612-d0d0c840f7e2@github.com>
Message-ID: <gPEKxHIm3NN_bkh3M2XhaoIofBY5m-_BgavichIr8kg=.db204df8-6fef-4d7c-8ec8-1602f4122ea6@github.com>

On Thu, 5 Oct 2023 06:40:32 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move log suspension out of VM thread.
>
> src/hotspot/share/runtime/crac.cpp line 439:
> 
>> 437:   }
>> 438:   if (cr.ok()) {
>> 439:     LogConfiguration::reopen();
> 
> Looks like the log stays closed & blocked if the checkpoint fails?

Hopefully it is fixed now?

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

PR Review Comment: https://git.openjdk.org/crac/pull/113#discussion_r1346938993

From rvansa at openjdk.org  Thu Oct  5 14:21:08 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Oct 2023 14:21:08 GMT
Subject: [crac] RFR: Persist memory in-JVM [v8]
In-Reply-To: <si44d9Hfekno9FBJbKEuAUPeuA3eqQaYQweHTNosS18=.8388c83a-4c6c-4e23-aae9-3a794efedaa4@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
 <si44d9Hfekno9FBJbKEuAUPeuA3eqQaYQweHTNosS18=.8388c83a-4c6c-4e23-aae9-3a794efedaa4@github.com>
Message-ID: <8gEJkR4zP6Vxfa7seGhWkBIXpPM_lUZQr3F4It5f0kA=.d53b18aa-11b0-46ec-be26-213183d3dc38@github.com>

On Wed, 4 Oct 2023 12:54:42 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
>> 
>> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
>> 
>> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
>> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
>> 
>> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.
>
> Radim Vansa has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix x86 build
>  - Use number of threads directly
>  - Don't persist CodeCache used for non-nMethods
>    
>    The stubs allocated in this heap are used for atomic operations on
>    aarch64, avoiding them before the memory is restored would be complicated.
>  - Fix close() on windows
>  - Add overrides (OSX build fix)
>  - Fix recursiveCheckpoint

After some attempts to avoid allocations when CodeCache is unmapped I resolved this by not persisting the non-nmethod part of CodeCache as not being able to allocate/free can be difficult e.g. when we're receiving (arbitrary number of) new parameters on restore, and requires blocking all native threads.

Other notable fix is a fix for pauseengine/simengine - it's not possible to mmaping the memory for these, it must be just read in.

I've also fixed the x86 (ia32) build. There's a checkpoint issue (on Java side) which I'll file as a separate PR; with the fix I can verify ia32 is running fine. While we don't have to put too much effort into ia32 per se, testing 32 bit revealed some problems that could manifest on 64 bit and would be much harder to reproduce. The most important one (architecture-wise) was that the code can mmap new regions before the persisted memory is reloaded. Later on the loading code would silently overwrite those.
This is now avoided by mmaping the regions recorded in index earlier on (e.g. before reading new paremeters from shm) an mapping them with PROT_NONE; mmaps without `MAP_FIXED` won't acquire those. This problem is less likely to happen with more sparse 64 bit address space but on ia32 this happened reliably.

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

PR Comment: https://git.openjdk.org/crac/pull/95#issuecomment-1748946554

From rvansa at openjdk.org  Thu Oct  5 15:23:15 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Oct 2023 15:23:15 GMT
Subject: [crac] RFR: Persist memory in-JVM [v9]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <u1YRQM8wTTCa7nm_P3KbDgBA4tC-nNnO1XnkQi6746g=.5e5c7a46-8533-45ca-b280-ccdfabc62c45@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Fix build on non-linux
 - Fix issues manifesting on ia32
   
   * reinit memory early during restore
   * use native size for fields in index
   * fix syscall passing too long pointer (64bit) on 32bit
   * fix various bugs in code

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

Changes:
  - all: https://git.openjdk.org/crac/pull/95/files
  - new: https://git.openjdk.org/crac/pull/95/files/78dfa7cb..11b4a04e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=95&range=08
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=95&range=07-08

  Stats: 145 lines in 8 files changed: 66 ins; 19 del; 60 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From jkratochvil at openjdk.org  Thu Oct  5 15:24:27 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 15:24:27 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v5]
In-Reply-To: <cQD1s96fgUjielZxVpu_hUX5PrVFkOiEu0nQosUdOkc=.e109cfd8-660d-4250-b2cf-5211c9362dee@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <cQD1s96fgUjielZxVpu_hUX5PrVFkOiEu0nQosUdOkc=.e109cfd8-660d-4250-b2cf-5211c9362dee@github.com>
Message-ID: <-TcOVVdJt0YRbAadg_33l8mrDnOT5fabQ63AwF73jho=.d14eb1a7-7814-47ca-a39d-cb94a58e27b1@github.com>

On Thu, 5 Oct 2023 07:31:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not keep logs closed if snapshot failed
>    - bugreported by Radim Vansa

There is a GHA error...

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

PR Comment: https://git.openjdk.org/crac/pull/113#issuecomment-1748626556

From jkratochvil at openjdk.org  Thu Oct  5 15:24:23 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 15:24:23 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v6]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <eNWrrD7Qy_ybEbSnAnY9eN3z8HLaVFJ1-o9zYfnrRIc=.02e9173a-0b3d-44cb-8a4d-7723c247d644@github.com>

> CRaC: Fix fds opened for logging

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

  Attempt to solve a compilation error from GHA:
    /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::stop()':
    src/hotspot/share/logging/logAsyncWriter.hpp:202: undefined reference to `PlatformMutex::lock()'
    /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::resume()':
    src/hotspot/share/logging/logAsyncWriter.hpp:203: undefined reference to `PlatformMutex::unlock()'
    /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::stop()':
    src/hotspot/share/logging/logAsyncWriter.hpp:202: undefined reference to `PlatformMutex::lock()'
    /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::resume()':
    src/hotspot/share/logging/logAsyncWriter.hpp:203: undefined reference to `PlatformMutex::unlock()'

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/b941490f..a79974a4

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

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

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

From rvansa at openjdk.org  Thu Oct  5 15:24:26 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Oct 2023 15:24:26 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v5]
In-Reply-To: <cQD1s96fgUjielZxVpu_hUX5PrVFkOiEu0nQosUdOkc=.e109cfd8-660d-4250-b2cf-5211c9362dee@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <cQD1s96fgUjielZxVpu_hUX5PrVFkOiEu0nQosUdOkc=.e109cfd8-660d-4250-b2cf-5211c9362dee@github.com>
Message-ID: <R1gc5TQu-UCr3zRhinRvNWixx-U_oMfcrr9IQ27WE2M=.723acd82-977c-473a-a3fd-cecbe8bb6410@github.com>

On Thu, 5 Oct 2023 07:31:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not keep logs closed if snapshot failed
>    - bugreported by Radim Vansa

LGTM, thank you!

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/113#pullrequestreview-1659683801

From jkratochvil at openjdk.org  Thu Oct  5 15:40:28 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 15:40:28 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v6]
In-Reply-To: <eNWrrD7Qy_ybEbSnAnY9eN3z8HLaVFJ1-o9zYfnrRIc=.02e9173a-0b3d-44cb-8a4d-7723c247d644@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <eNWrrD7Qy_ybEbSnAnY9eN3z8HLaVFJ1-o9zYfnrRIc=.02e9173a-0b3d-44cb-8a4d-7723c247d644@github.com>
Message-ID: <ypoXuDtSp-nNrA1gn-_NLgVouRBU41R_QOBlyPsq7x8=.5d4ac143-1bc9-46f5-bfbe-5e835327ba93@github.com>

On Thu, 5 Oct 2023 15:24:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attempt to solve a compilation error from GHA:
>     /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::stop()':
>     src/hotspot/share/logging/logAsyncWriter.hpp:202: undefined reference to `PlatformMutex::lock()'
>     /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::resume()':
>     src/hotspot/share/logging/logAsyncWriter.hpp:203: undefined reference to `PlatformMutex::unlock()'
>     /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::stop()':
>     src/hotspot/share/logging/logAsyncWriter.hpp:202: undefined reference to `PlatformMutex::lock()'
>     /usr/bin/ld: build/linux-x64/hotspot/variant-zero/libjvm/objs/crac.o: in function `AsyncLogWriter::resume()':
>     src/hotspot/share/logging/logAsyncWriter.hpp:203: undefined reference to `PlatformMutex::unlock()'

Please do not sponsor it yet, maybe there is really some OSX compilation regression.

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

PR Comment: https://git.openjdk.org/crac/pull/113#issuecomment-1749153061

From jkratochvil at openjdk.org  Thu Oct  5 15:47:27 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 15:47:27 GMT
Subject: [crac] RFR: Fix compilation with clang
Message-ID: <MxMNJkCMufYHa1RlQ_BhtT8yV39qiMNwnDyNe0fSjMI=.b67ea53f-87db-4a9d-8337-bf30b518911b@github.com>

../../src/hotspot/os/linux/crac_linux.cpp:192:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
  while (dp = readdir(dir)) {
         ~~~^~~~~~~~~~~~~~
../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: place parentheses around the assignment to silence this warning
  while (dp = readdir(dir)) {
            ^
         (                )
../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: use '==' to turn this assignment into an equality comparison
  while (dp = readdir(dir)) {
            ^
            ==
../../src/hotspot/os/linux/crac_linux.cpp:402:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
  while (dp = readdir(dir)) {
         ~~~^~~~~~~~~~~~~~
../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: place parentheses around the assignment to silence this warning
  while (dp = readdir(dir)) {
            ^
         (                )
../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: use '==' to turn this assignment into an equality comparison
  while (dp = readdir(dir)) {
            ^
            ==
2 errors generated.

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

Commit messages:
 - Fix compilation with clang

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

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

From jkratochvil at openjdk.org  Thu Oct  5 16:23:45 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 5 Oct 2023 16:23:45 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v7]
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <6M2n-EYHwJrk68TvprpTLJQr-dHm50DrYD_kSbcjBbs=.e6772ac8-0c20-4e7a-8aa5-3ffbef814a56@github.com>

> CRaC: Fix fds opened for logging

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

  Fix clang compilation -Werror warnings

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

Changes:
  - all: https://git.openjdk.org/crac/pull/113/files
  - new: https://git.openjdk.org/crac/pull/113/files/a79974a4..02a5fab3

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

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

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

From rvansa at openjdk.org  Fri Oct  6 06:57:35 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 06:57:35 GMT
Subject: [crac] RFR: Fix compilation with clang
In-Reply-To: <MxMNJkCMufYHa1RlQ_BhtT8yV39qiMNwnDyNe0fSjMI=.b67ea53f-87db-4a9d-8337-bf30b518911b@github.com>
References: <MxMNJkCMufYHa1RlQ_BhtT8yV39qiMNwnDyNe0fSjMI=.b67ea53f-87db-4a9d-8337-bf30b518911b@github.com>
Message-ID: <GcsnqEsM3JLiD7FN6Lu_V7ryM5TETq5VkCCgTbnzixs=.f047b04a-baa2-4e9c-b439-4ce4f95f7bc3@github.com>

On Thu, 5 Oct 2023 15:38:55 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>   while (dp = readdir(dir)) {
>          ~~~^~~~~~~~~~~~~~
> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: place parentheses around the assignment to silence this warning
>   while (dp = readdir(dir)) {
>             ^
>          (                )
> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: use '==' to turn this assignment into an equality comparison
>   while (dp = readdir(dir)) {
>             ^
>             ==
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>   while (dp = readdir(dir)) {
>          ~~~^~~~~~~~~~~~~~
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: place parentheses around the assignment to silence this warning
>   while (dp = readdir(dir)) {
>             ^
>          (                )
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: use '==' to turn this assignment into an equality comparison
>   while (dp = readdir(dir)) {
>             ^
>             ==
> 2 errors generated.

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/122#pullrequestreview-1661222184

From rvansa at openjdk.org  Fri Oct  6 07:10:33 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 07:10:33 GMT
Subject: [crac] RFR: CRaC: Fix fds opened for logging [v7]
In-Reply-To: <6M2n-EYHwJrk68TvprpTLJQr-dHm50DrYD_kSbcjBbs=.e6772ac8-0c20-4e7a-8aa5-3ffbef814a56@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
 <6M2n-EYHwJrk68TvprpTLJQr-dHm50DrYD_kSbcjBbs=.e6772ac8-0c20-4e7a-8aa5-3ffbef814a56@github.com>
Message-ID: <fkB_g04b7VtNpLb31EDdMS46-_v0amJ44BT53dk6Vz4=.13279887-bb68-43c4-bacf-38b858c22d65@github.com>

On Thu, 5 Oct 2023 16:23:45 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> CRaC: Fix fds opened for logging
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clang compilation -Werror warnings

The build looks good, please set to integrate again.

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

PR Comment: https://git.openjdk.org/crac/pull/113#issuecomment-1750090216

From rvansa at openjdk.org  Fri Oct  6 08:10:17 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 08:10:17 GMT
Subject: [crac] RFR: Persist memory in-JVM [v10]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <-AAgO5ziLiuXJ7VISbH5rCCtPfDYMEHTI5Vx3EgNICI=.bbedf232-fa9c-4170-932e-a24d1429d0f5@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

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

  Try fix other platforms

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

Changes:
  - all: https://git.openjdk.org/crac/pull/95/files
  - new: https://git.openjdk.org/crac/pull/95/files/11b4a04e..37819a6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=95&range=09
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=95&range=08-09

  Stats: 93 lines in 6 files changed: 31 ins; 45 del; 17 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From jkratochvil at openjdk.org  Fri Oct  6 11:15:34 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 6 Oct 2023 11:15:34 GMT
Subject: [crac] Integrated: CRaC: Fix fds opened for logging
In-Reply-To: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
References: <ZP-0GShFSEHhiNW6DGPjYDOBDrHltGrExzYBhHFQ1QI=.d0bc4465-d0be-4bff-8ca6-2fb1f8c880e1@github.com>
Message-ID: <nv3wajeCAwbtD6uT9sjC9PpxgokeEUFQnNTHmUkP6Uo=.4522fd1e-06d0-41d8-bb92-a71348044abe@github.com>

On Tue, 19 Sep 2023 14:30:15 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> CRaC: Fix fds opened for logging

This pull request has now been integrated.

Changeset: dc16f1da
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/dc16f1da298f8f9162e3e8634d2aa7690e05e1c6
Stats:     183 lines in 11 files changed: 170 ins; 0 del; 13 mod

CRaC: Fix fds opened for logging

Reviewed-by: rvansa

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

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

From jkratochvil at openjdk.org  Fri Oct  6 11:15:28 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 6 Oct 2023 11:15:28 GMT
Subject: [crac] Integrated: Fix compilation with clang
In-Reply-To: <MxMNJkCMufYHa1RlQ_BhtT8yV39qiMNwnDyNe0fSjMI=.b67ea53f-87db-4a9d-8337-bf30b518911b@github.com>
References: <MxMNJkCMufYHa1RlQ_BhtT8yV39qiMNwnDyNe0fSjMI=.b67ea53f-87db-4a9d-8337-bf30b518911b@github.com>
Message-ID: <eElYWN5v53bNFTKxjhT9beHbx4CXKQVjDQl1kROuTsY=.74ec4a8e-ac7a-4538-9080-a90adee69c61@github.com>

On Thu, 5 Oct 2023 15:38:55 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>   while (dp = readdir(dir)) {
>          ~~~^~~~~~~~~~~~~~
> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: place parentheses around the assignment to silence this warning
>   while (dp = readdir(dir)) {
>             ^
>          (                )
> ../../src/hotspot/os/linux/crac_linux.cpp:192:13: note: use '==' to turn this assignment into an equality comparison
>   while (dp = readdir(dir)) {
>             ^
>             ==
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
>   while (dp = readdir(dir)) {
>          ~~~^~~~~~~~~~~~~~
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: place parentheses around the assignment to silence this warning
>   while (dp = readdir(dir)) {
>             ^
>          (                )
> ../../src/hotspot/os/linux/crac_linux.cpp:402:13: note: use '==' to turn this assignment into an equality comparison
>   while (dp = readdir(dir)) {
>             ^
>             ==
> 2 errors generated.

This pull request has now been integrated.

Changeset: b6d39f11
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/b6d39f11bc216c097dcc255a37e859b6c8d01144
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

Fix compilation with clang

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Fri Oct  6 11:23:00 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 11:23:00 GMT
Subject: [crac] RFR: Persist memory in-JVM [v11]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <38x5Pn_mYikGvIabE9kPiNkEPGbZYu62uEXIVDEso7Y=.4a8bb200-5f39-4ef9-aa36-f41ea36fe6e3@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

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

  Another attempt to fix Win & OSX

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

Changes:
  - all: https://git.openjdk.org/crac/pull/95/files
  - new: https://git.openjdk.org/crac/pull/95/files/37819a6b..be580c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=95&range=10
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=95&range=09-10

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

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

From rvansa at openjdk.org  Fri Oct  6 13:20:32 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 13:20:32 GMT
Subject: [crac] RFR: Fix OSX failure in SunMiscSignalTest
Message-ID: <sEJeVIcWefJaVY0UyrOCH7zPl8Xdr4s1zLklyjken0s=.ab0d3022-4170-4489-b695-738c662975eb@github.com>

Fixes GHA failure in SunMiscSignalTest on OSX

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

Commit messages:
 - Fix OSX failure in SunMiscSignalTest

Changes: https://git.openjdk.org/crac/pull/123/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=123&range=00
  Stats: 6 lines in 2 files changed: 4 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/crac/pull/123.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/123/head:pull/123

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

From rvansa at openjdk.org  Fri Oct  6 13:23:13 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 13:23:13 GMT
Subject: [crac] RFR: Handle C/R in BasicImageReader (via reflection)
Message-ID: <fDGMxqIuLYq-Rvw2nE9A_Z-GioszV8TnzGTsJO4AZhY=.39cb1340-bbca-43d8-82c3-66a293f70489@github.com>

Fixes checkpoint failure due to open FD to modules on x86 (the Java code behaves differently on 32bit and 64bt).

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

Commit messages:
 - Handle C/R in BasicImageReader (via reflection)

Changes: https://git.openjdk.org/crac/pull/124/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=124&range=00
  Stats: 112 lines in 1 file changed: 86 ins; 22 del; 4 mod
  Patch: https://git.openjdk.org/crac/pull/124.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/124/head:pull/124

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

From rvansa at openjdk.org  Fri Oct  6 13:24:56 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 13:24:56 GMT
Subject: [crac] RFR: Stabilize GHA testsuite
Message-ID: <79rGmrItxYDFygbMRycCnfgunRHRtY2w9w9be9vFICU=.92f04e17-9266-41e8-9f60-5f81022b6132@github.com>

At this point Github Actions always show some failures; let's ignore platforms that we don't handle for CRaC and some problematic tests in mainline JDK.

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

Commit messages:
 - ProblemList test runtime/ClassInitErrors/TestStackOverflowDuringInit.java
 - Exclude s390, ppc64le and riscv64 from build

Changes: https://git.openjdk.org/crac/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=125&range=00
  Stats: 20 lines in 2 files changed: 2 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/crac/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/125/head:pull/125

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

From rvansa at openjdk.org  Fri Oct  6 15:27:27 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Oct 2023 15:27:27 GMT
Subject: [crac] RFR: Persist memory in-JVM [v12]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <HjdjtabDFBT1kQjVuDz01MnvJQT_2IwvXvFAXuNPQjw=.252f76ed-e10a-47d7-8994-31d69f611a00@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - maybe fixup
 - Merge branch 'crac' into persist_memory
 - Another attempt to fix Win & OSX
 - Try fix other platforms
 - Fix build on non-linux
 - Fix issues manifesting on ia32
   
   * reinit memory early during restore
   * use native size for fields in index
   * fix syscall passing too long pointer (64bit) on 32bit
   * fix various bugs in code
 - Fix x86 build
 - Use number of threads directly
 - Don't persist CodeCache used for non-nMethods
   
   The stubs allocated in this heap are used for atomic operations on
   aarch64, avoiding them before the memory is restored would be complicated.
 - Fix close() on windows
 - ... and 39 more: https://git.openjdk.org/crac/compare/b6d39f11...6a215b41

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

Changes: https://git.openjdk.org/crac/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=95&range=11
  Stats: 1368 lines in 37 files changed: 1312 ins; 29 del; 27 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From akozlov at openjdk.org  Thu Oct 12 14:23:51 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Thu, 12 Oct 2023 14:23:51 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v2]
In-Reply-To: <mng8ItVRx4E1Ai2amtUDW-Iz-jCOwSNWAmwkD3G8AXE=.14e19a19-4160-4786-8810-055a5c24124e@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
 <mng8ItVRx4E1Ai2amtUDW-Iz-jCOwSNWAmwkD3G8AXE=.14e19a19-4160-4786-8810-055a5c24124e@github.com>
Message-ID: <-9ATcgIRdSIu5pNkyQcLe77SdRWc3z_9HznGH6IPXa4=.3bf77a09-065e-4be0-b7ae-58530f30c51a@github.com>

On Mon, 2 Oct 2023 19:51:51 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
>> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jcmd <pid> PerfCounter.print to the test

It should be possible to remove 

static int checkpoint_fd = -1;


from https://github.com/openjdk/crac/pull/119/files#diff-7313eb3d328797a7720fa1b2b73cd159934506593443e45534baad80cb1382b7R66

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

PR Review: https://git.openjdk.org/crac/pull/119#pullrequestreview-1674179076

From rvansa at openjdk.org  Thu Oct 12 15:42:00 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 12 Oct 2023 15:42:00 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v3]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <vYi4cNQhY_DNcegvSjVSSDCmC-e36zT6Myjau-8lUuI=.2ec54fdf-25fb-4f88-8ec6-4613beb43b52@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Remove forgotten global variable

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/bd6adcc8..bc8cf838

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

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

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

From rvansa at openjdk.org  Thu Oct 12 15:47:27 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 12 Oct 2023 15:47:27 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v4]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <IR8RY_YoRVwj-5628Nd2MkfUfLVZ70eSUzmMT7mq8N4=.91e4bbaf-eb68-4d07-8f96-0959c280bc1f@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Fixup for previous commit

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/bc8cf838..79298fd2

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

  Stats: 73 lines in 1 file changed: 15 ins; 43 del; 15 mod
  Patch: https://git.openjdk.org/crac/pull/119.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/119/head:pull/119

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

From rvansa at openjdk.org  Fri Oct 13 12:28:20 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 13 Oct 2023 12:28:20 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v5]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <nbYz0rlAeHmsnQopO79MOlimXuJ60TplgTUu4r2-wyw=.2667c3b3-61a0-4a5a-87e5-c177a3cdd276@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Fix NPE in some tests

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/79298fd2..da777fd5

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

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

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

From rvansa at openjdk.org  Fri Oct 13 14:31:17 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 13 Oct 2023 14:31:17 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v6]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <xpzczMcseqgPLnZAoJD24pFVYI4mpae9xYpbdDBt0Gc=.fa57b62b-3abd-43f6-afdd-c258c7a42368@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Add timeouts to the test

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/da777fd5..0309d72a

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

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

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

From rvansa at openjdk.org  Fri Oct 13 15:39:35 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 13 Oct 2023 15:39:35 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v7]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Use hardcoded path

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/0309d72a..ce6cb495

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

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

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

From rvansa at openjdk.org  Fri Oct 13 20:33:01 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 13 Oct 2023 20:33:01 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v2]
In-Reply-To: <-9ATcgIRdSIu5pNkyQcLe77SdRWc3z_9HznGH6IPXa4=.3bf77a09-065e-4be0-b7ae-58530f30c51a@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
 <mng8ItVRx4E1Ai2amtUDW-Iz-jCOwSNWAmwkD3G8AXE=.14e19a19-4160-4786-8810-055a5c24124e@github.com>
 <-9ATcgIRdSIu5pNkyQcLe77SdRWc3z_9HznGH6IPXa4=.3bf77a09-065e-4be0-b7ae-58530f30c51a@github.com>
Message-ID: <s9V__4llAfoybkhA9S9vPVrh5x7b-KFFERC_OoJ7Nps=.c5a91bef-7a81-4eec-936d-307a7e85c1bb@github.com>

On Thu, 12 Oct 2023 13:26:03 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add jcmd <pid> PerfCounter.print to the test
>
> It should be possible to remove 
> 
> static int checkpoint_fd = -1;
> 
> 
> from https://github.com/openjdk/crac/pull/119/files#diff-7313eb3d328797a7720fa1b2b73cd159934506593443e45534baad80cb1382b7R66

@AntonKozlov Done. I also had to fixup the test, as in GHA the temp directory was set to a local folder and actually it has to be hardcoded to `/tmp` on Linux (local testing did not reveal that).

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

PR Comment: https://git.openjdk.org/crac/pull/119#issuecomment-1762160673

From duke at openjdk.org  Mon Oct 16 05:15:57 2023
From: duke at openjdk.org (Pushkar N Kulkarni)
Date: Mon, 16 Oct 2023 05:15:57 GMT
Subject: [crac] RFR: Update the "modified criu" link to the latest release
Message-ID: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>

The modified criu binary downloaded from the release that is linked from the README causes CRaC to segfault while checkpointing. Updating to the latest release helps resolve the problem.

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

Commit messages:
 - Update the "modified criu" link to the latest release

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

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

From duke at openjdk.org  Mon Oct 16 05:41:52 2023
From: duke at openjdk.org (Pushkar N Kulkarni)
Date: Mon, 16 Oct 2023 05:41:52 GMT
Subject: [crac] RFR: Update the "modified criu" link to the latest release
 [v2]
In-Reply-To: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
References: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
Message-ID: <Gw97T2lPnfytn8sTx_BOIBotyH_OLn9uL3R7G9ZlkpQ=.7934eb5d-b8bf-45dc-bc4f-0d04f1f1c887@github.com>

> The modified criu binary downloaded from the release that is linked from the README causes CRaC to segfault while checkpointing. Updating to the latest release helps resolve the problem.

Pushkar N Kulkarni has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

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

Changes:
  - all: https://git.openjdk.org/crac/pull/126/files
  - new: https://git.openjdk.org/crac/pull/126/files/10fc10e2..3bc972ad

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

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

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

From rvansa at openjdk.org  Mon Oct 16 07:39:37 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 16 Oct 2023 07:39:37 GMT
Subject: [crac] RFR: Update the "modified criu" link to the latest release
 [v2]
In-Reply-To: <Gw97T2lPnfytn8sTx_BOIBotyH_OLn9uL3R7G9ZlkpQ=.7934eb5d-b8bf-45dc-bc4f-0d04f1f1c887@github.com>
References: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
 <Gw97T2lPnfytn8sTx_BOIBotyH_OLn9uL3R7G9ZlkpQ=.7934eb5d-b8bf-45dc-bc4f-0d04f1f1c887@github.com>
Message-ID: <pw3bpTRRstjo4KCyya9l-uWFFWwacMMifSdB2ggAJMs=.c1bee80a-ab48-473a-b800-06268d6d16a1@github.com>

On Mon, 16 Oct 2023 05:41:52 GMT, Pushkar N Kulkarni <duke at openjdk.org> wrote:

>> The modified criu binary downloaded from the release that is linked from the README causes CRaC to segfault while checkpointing. Updating to the latest release helps resolve the problem.
>
> Pushkar N Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Thanks for the correction!

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/126#pullrequestreview-1679308568

From jkratochvil at openjdk.org  Mon Oct 16 11:45:35 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 16 Oct 2023 11:45:35 GMT
Subject: [crac] RFR: -XX:+ShowCPUFeatures: Fix double 0x (0x0x)
Message-ID: <IQU-56tF90kFZRjhgZQC31ydPHa3aeUt6i7w0A7venQ=.e5ab2c7d-35c5-430b-bb0d-a3db9000f37b@github.com>

- `CPU features being used are: -XX:CPUFeatures=0x0x4ff7fff9dfcfbf7,0x0x3e6`

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

Commit messages:
 - -XX:+ShowCPUFeatures: Fix double 0x (0x0x)

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

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

From rvansa at openjdk.org  Mon Oct 16 11:59:13 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 16 Oct 2023 11:59:13 GMT
Subject: [crac] RFR: Persist memory in-JVM [v13]
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <aRPexhYM6xDiJo3v3buKSUTCQoGtzSWVhRC48GYtGiw=.ccf48f13-4e83-47bb-8988-09871b8e072b@github.com>

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:

 - Revert changes not needed anymore in vm_version
 - Windows build fix
 - Refactored to fix OSX

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

Changes:
  - all: https://git.openjdk.org/crac/pull/95/files
  - new: https://git.openjdk.org/crac/pull/95/files/6a215b41..b23f9246

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=95&range=12
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=95&range=11-12

  Stats: 403 lines in 17 files changed: 178 ins; 174 del; 51 mod
  Patch: https://git.openjdk.org/crac/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/95/head:pull/95

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

From rvansa at openjdk.org  Tue Oct 17 06:17:57 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 17 Oct 2023 06:17:57 GMT
Subject: [crac] RFR: -XX:+ShowCPUFeatures: Fix double 0x (0x0x)
In-Reply-To: <IQU-56tF90kFZRjhgZQC31ydPHa3aeUt6i7w0A7venQ=.e5ab2c7d-35c5-430b-bb0d-a3db9000f37b@github.com>
References: <IQU-56tF90kFZRjhgZQC31ydPHa3aeUt6i7w0A7venQ=.e5ab2c7d-35c5-430b-bb0d-a3db9000f37b@github.com>
Message-ID: <tMRCHlRQc25OS88FIWuFYsr0jEWqAZTu_Fp9zYJOVtI=.81fdbb94-59f0-4926-bf88-9797f76f390c@github.com>

On Mon, 16 Oct 2023 11:38:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> - `CPU features being used are: -XX:CPUFeatures=0x0x4ff7fff9dfcfbf7,0x0x3e6`

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/127#pullrequestreview-1681437154

From rvansa at openjdk.org  Tue Oct 17 06:37:58 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 17 Oct 2023 06:37:58 GMT
Subject: [crac] RFR: Update the "modified criu" link to the latest release
 [v2]
In-Reply-To: <Gw97T2lPnfytn8sTx_BOIBotyH_OLn9uL3R7G9ZlkpQ=.7934eb5d-b8bf-45dc-bc4f-0d04f1f1c887@github.com>
References: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
 <Gw97T2lPnfytn8sTx_BOIBotyH_OLn9uL3R7G9ZlkpQ=.7934eb5d-b8bf-45dc-bc4f-0d04f1f1c887@github.com>
Message-ID: <eOLY6Bsps0SvCc5oc79jmWIkdQMWC0YWIvHUPAWpMWw=.339bd758-5223-4c14-a52c-774f0ad34628@github.com>

On Mon, 16 Oct 2023 05:41:52 GMT, Pushkar N Kulkarni <duke at openjdk.org> wrote:

>> The modified criu binary downloaded from the release that is linked from the README causes CRaC to segfault while checkpointing. Updating to the latest release helps resolve the problem.
>
> Pushkar N Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

@pushkarnk Could you please type in the `/integrate` command?

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

PR Comment: https://git.openjdk.org/crac/pull/126#issuecomment-1765758338

From duke at openjdk.org  Tue Oct 17 07:07:56 2023
From: duke at openjdk.org (Pushkar N Kulkarni)
Date: Tue, 17 Oct 2023 07:07:56 GMT
Subject: [crac] Integrated: Update the "modified criu" link to the latest
 release
In-Reply-To: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
References: <nWLj-Muj1j1uJ6sxSNm58j-SODyx73TFGaSGtmjrPLQ=.906b35e6-7718-46b4-8260-916517cf81c6@github.com>
Message-ID: <NCOKTf3G7iBPEt65qLzvI14ioeerjPhXbFHjgHfhboA=.614cd0b6-de67-45dd-9111-b419e6f30855@github.com>

On Mon, 16 Oct 2023 05:07:57 GMT, Pushkar N Kulkarni <duke at openjdk.org> wrote:

> The modified criu binary downloaded from the release that is linked from the README causes CRaC to segfault while checkpointing. Updating to the latest release helps resolve the problem.

This pull request has now been integrated.

Changeset: ba0087fc
Author:    Pushkar N Kulkarni <pushkar.kulkarni at canonical.com>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/ba0087fca72ae0f21351fd7bd8d1e7926175b860
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Update the "modified criu" link to the latest release

Reviewed-by: rvansa

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

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

From jkratochvil at openjdk.org  Tue Oct 17 07:10:53 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 17 Oct 2023 07:10:53 GMT
Subject: [crac] Integrated: -XX:+ShowCPUFeatures: Fix double 0x (0x0x)
In-Reply-To: <IQU-56tF90kFZRjhgZQC31ydPHa3aeUt6i7w0A7venQ=.e5ab2c7d-35c5-430b-bb0d-a3db9000f37b@github.com>
References: <IQU-56tF90kFZRjhgZQC31ydPHa3aeUt6i7w0A7venQ=.e5ab2c7d-35c5-430b-bb0d-a3db9000f37b@github.com>
Message-ID: <4aTIHFBk16qZjmygYVcwVH77t7Qli0cuKpD8V5e9RwM=.62a8fb2a-a7c1-4b5f-9c44-a33266714c87@github.com>

On Mon, 16 Oct 2023 11:38:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> - `CPU features being used are: -XX:CPUFeatures=0x0x4ff7fff9dfcfbf7,0x0x3e6`

This pull request has now been integrated.

Changeset: 396db644
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/396db64430b00c734a1538c2133cc6ddfb9264c5
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

-XX:+ShowCPUFeatures: Fix double 0x (0x0x)

Reviewed-by: rvansa

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

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

From rvansa at openjdk.org  Tue Oct 17 07:37:35 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 17 Oct 2023 07:37:35 GMT
Subject: [crac] RFR: Fix test when running as root
Message-ID: <J0GWJWpxG1zpA4A4RpFHOtz4DY5FwNPW91wdIXGFbuU=.ed325f79-eca0-4f1d-b38d-94339b145680@github.com>

Root can reopen the file even without permissions.

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

Commit messages:
 - Fix test when running as root

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

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

From jkratochvil at openjdk.org  Tue Oct 17 07:58:44 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 17 Oct 2023 07:58:44 GMT
Subject: [crac] RFR: Fix test when running as root
In-Reply-To: <J0GWJWpxG1zpA4A4RpFHOtz4DY5FwNPW91wdIXGFbuU=.ed325f79-eca0-4f1d-b38d-94339b145680@github.com>
References: <J0GWJWpxG1zpA4A4RpFHOtz4DY5FwNPW91wdIXGFbuU=.ed325f79-eca0-4f1d-b38d-94339b145680@github.com>
Message-ID: <uvdHDJcJTBDICa4qBPgN_ga-yBfDiftC4NNV2JZ8v_I=.e773bae6-8f7d-42c1-a5d0-d287958c79e6@github.com>

On Tue, 17 Oct 2023 07:28:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Root can reopen the file even without permissions.

Yes, it does work for me now, thanks.

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

PR Comment: https://git.openjdk.org/crac/pull/128#issuecomment-1765871584

From rmarchenko at openjdk.org  Tue Oct 17 08:59:13 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 17 Oct 2023 08:59:13 GMT
Subject: [crac] RFR: Fixing crash on restore when user name is not set
Message-ID: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>

This change fixes a crash occuring during restore in a container when user name is not set.

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

Commit messages:
 - Fixing crash on restore when user name is not set

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

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

From rmarchenko at openjdk.org  Tue Oct 17 09:36:11 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 17 Oct 2023 09:36:11 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime flag)
Message-ID: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>

This change adds an opportunity reset both JVM's start time and uptime on restoring.

Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".

The flag is 'false' by default.

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

Commit messages:
 - Reset JVM start time and up time on restore (CRaCResetStartTime flag)

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

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

From rvansa at openjdk.org  Tue Oct 17 11:50:30 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 17 Oct 2023 11:50:30 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime)
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>

On Tue, 17 Oct 2023 09:29:35 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

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

> 466: 
> 467: void crac::initialize_time_counters() {
> 468:   os::Posix::init();

The initialization updates some condition variable attributes; have you checked if there's any chance that another  thread could observe an inconsistent state while this is updated?

test/jdk/jdk/crac/ResetStartTimeTest.java line 40:

> 38:  * @library /test/lib
> 39:  * @build SimpleTest
> 40:  * @requires (os.family == "linux")

I think that if you use simengine the test is applicable to other platforms as well.

test/jdk/jdk/crac/ResetStartTimeTest.java line 44:

> 42:  * @run driver/timeout=60 jdk.test.lib.crac.CracTest true
> 43:  */
> 44: public class SimpleTest implements CracTest {

Could you please name the test `ResetStartTimeTest` to match the filename?

test/jdk/jdk/crac/ResetStartTimeTest.java line 75:

> 73:             assertLessThan(uptime1, WAIT_TIMEOUT);
> 74:         } else {
> 75:             assertLessThan(uptime0, uptime1);

If the C/R is really quick this should be <=

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1361985624
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1361962742
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1361959649
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1361962107

From rvansa at openjdk.org  Tue Oct 17 11:53:41 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 17 Oct 2023 11:53:41 GMT
Subject: [crac] RFR: Fixing crash on restore when user name is not set
In-Reply-To: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
References: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
Message-ID: <hLjiOHFvMFKIPNlNUNACtT-B3a8SIA0UvVAGdCOYtrY=.22ee3480-052f-4080-977b-4605821ea201@github.com>

On Tue, 17 Oct 2023 08:53:02 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes a crash occuring during restore in a container when user name is not set.

src/hotspot/os/posix/perfMemory_posix.cpp line 1405:

> 1403:   char* user_name = get_user_name(geteuid());
> 1404:   if (!user_name) {
> 1405:     return false;

Could we accompany this with an error message?

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

PR Review Comment: https://git.openjdk.org/crac/pull/129#discussion_r1361990839

From rmarchenko at openjdk.org  Wed Oct 18 07:29:37 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 07:29:37 GMT
Subject: [crac] RFR: Fixing crash on restore when user name is not set
In-Reply-To: <hLjiOHFvMFKIPNlNUNACtT-B3a8SIA0UvVAGdCOYtrY=.22ee3480-052f-4080-977b-4605821ea201@github.com>
References: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
 <hLjiOHFvMFKIPNlNUNACtT-B3a8SIA0UvVAGdCOYtrY=.22ee3480-052f-4080-977b-4605821ea201@github.com>
Message-ID: <guNiN0HsS3jBOEip-jOEZVerC9WPQ7m0p7X3CmSaUCU=.72c804b1-fe13-4a72-9159-b937e2bed9ca@github.com>

On Tue, 17 Oct 2023 11:51:08 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This change fixes a crash occuring during restore in a container when user name is not set.
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 1405:
> 
>> 1403:   char* user_name = get_user_name(geteuid());
>> 1404:   if (!user_name) {
>> 1405:     return false;
> 
> Could we accompany this with an error message?

I'm not sure about an error message as it doesn't fail restore procedure. 
The same scenario from [here ](https://github.com/openjdk/crac/blob/crac/src/hotspot/os/posix/perfMemory_posix.cpp#L1032) doesn't show any message also.

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

PR Review Comment: https://git.openjdk.org/crac/pull/129#discussion_r1363376921

From rvansa at openjdk.org  Wed Oct 18 08:27:06 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 18 Oct 2023 08:27:06 GMT
Subject: [crac] RFR: Fixing crash on restore when user name is not set
In-Reply-To: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
References: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
Message-ID: <50LnQyfUIeLZa3uw6eJtgG9HZGnjA4NlxJhDTM9MGQM=.af644d43-6b48-4ace-bea6-7b6fb71aa7af@github.com>

On Tue, 17 Oct 2023 08:53:02 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes a crash occuring during restore in a container when user name is not set.

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/129#pullrequestreview-1684376573

From rvansa at openjdk.org  Wed Oct 18 08:27:26 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 18 Oct 2023 08:27:26 GMT
Subject: [crac] RFR: Fixing crash on restore when user name is not set
In-Reply-To: <guNiN0HsS3jBOEip-jOEZVerC9WPQ7m0p7X3CmSaUCU=.72c804b1-fe13-4a72-9159-b937e2bed9ca@github.com>
References: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
 <hLjiOHFvMFKIPNlNUNACtT-B3a8SIA0UvVAGdCOYtrY=.22ee3480-052f-4080-977b-4605821ea201@github.com>
 <guNiN0HsS3jBOEip-jOEZVerC9WPQ7m0p7X3CmSaUCU=.72c804b1-fe13-4a72-9159-b937e2bed9ca@github.com>
Message-ID: <PDTM7sdMgQcITdpsxKUO6oVjAHolas-CKt7nHeK8z9c=.27570988-d0b0-4d5e-aa83-150b69f59156@github.com>

On Wed, 18 Oct 2023 07:26:28 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> src/hotspot/os/posix/perfMemory_posix.cpp line 1405:
>> 
>>> 1403:   char* user_name = get_user_name(geteuid());
>>> 1404:   if (!user_name) {
>>> 1405:     return false;
>> 
>> Could we accompany this with an error message?
>
> I'm not sure about an error message as it doesn't fail restore procedure. 
> The same scenario from [here ](https://github.com/openjdk/crac/blob/crac/src/hotspot/os/posix/perfMemory_posix.cpp#L1032) doesn't show any message also.

OK, that scenario would end up with an error message only with [develop flags](https://github.com/openjdk/crac/blob/crac/src/hotspot/os/posix/perfMemory_posix.cpp#L1261).

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

PR Review Comment: https://git.openjdk.org/crac/pull/129#discussion_r1363425156

From rmarchenko at openjdk.org  Wed Oct 18 08:28:18 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 08:28:18 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime)
In-Reply-To: <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>
Message-ID: <E7W7g1qYEvj2nV4hEP7DnvftDJAQ7mRkkHq_VOjaSdw=.33d022cb-7295-4663-99c6-2307496e9044@github.com>

On Tue, 17 Oct 2023 11:46:55 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This change adds an opportunity reset both JVM's start time and uptime on restoring.
>> 
>> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
>> 
>> The flag is 'false' by default.
>
> src/hotspot/os/linux/crac_linux.cpp line 468:
> 
>> 466: 
>> 467: void crac::initialize_time_counters() {
>> 468:   os::Posix::init();
> 
> The initialization updates some condition variable attributes; have you checked if there's any chance that another  thread could observe an inconsistent state while this is updated?

You're right, I missed it.

> test/jdk/jdk/crac/ResetStartTimeTest.java line 44:
> 
>> 42:  * @run driver/timeout=60 jdk.test.lib.crac.CracTest true
>> 43:  */
>> 44: public class SimpleTest implements CracTest {
> 
> Could you please name the test `ResetStartTimeTest` to match the filename?

Ye olde copy-n-paste :)
Thanks!

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363461639
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363417336

From rmarchenko at openjdk.org  Wed Oct 18 08:33:02 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 08:33:02 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v2]
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <gv4o0qAqkhIS48Erz06EPhowj9Me5ovLDFPLMlGxb4Q=.1b1055f4-ec0c-4fcc-a64c-7c5693ee7248@github.com>

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing review comments

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

Changes:
  - all: https://git.openjdk.org/crac/pull/130/files
  - new: https://git.openjdk.org/crac/pull/130/files/cd5b63eb..91913cb2

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

  Stats: 29 lines in 5 files changed: 14 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/crac/pull/130.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/130/head:pull/130

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

From rmarchenko at openjdk.org  Wed Oct 18 08:33:06 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 08:33:06 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v2]
In-Reply-To: <E7W7g1qYEvj2nV4hEP7DnvftDJAQ7mRkkHq_VOjaSdw=.33d022cb-7295-4663-99c6-2307496e9044@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>
 <E7W7g1qYEvj2nV4hEP7DnvftDJAQ7mRkkHq_VOjaSdw=.33d022cb-7295-4663-99c6-2307496e9044@github.com>
Message-ID: <AEtg7mpycZBheCKqe1-njFsQXim-40Fb3CKXsGIBDV0=.ffff82de-e135-4297-ac39-decb02d14b0e@github.com>

On Wed, 18 Oct 2023 08:24:49 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> src/hotspot/os/linux/crac_linux.cpp line 468:
>> 
>>> 466: 
>>> 467: void crac::initialize_time_counters() {
>>> 468:   os::Posix::init();
>> 
>> The initialization updates some condition variable attributes; have you checked if there's any chance that another  thread could observe an inconsistent state while this is updated?
>
> You're right, I missed it.

Done

>> test/jdk/jdk/crac/ResetStartTimeTest.java line 44:
>> 
>>> 42:  * @run driver/timeout=60 jdk.test.lib.crac.CracTest true
>>> 43:  */
>>> 44: public class SimpleTest implements CracTest {
>> 
>> Could you please name the test `ResetStartTimeTest` to match the filename?
>
> Ye olde copy-n-paste :)
> Thanks!

Done

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363475223
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363474387

From rmarchenko at openjdk.org  Wed Oct 18 08:33:08 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 08:33:08 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v2]
In-Reply-To: <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <tgXU2s4UhTXWuhrML6TTxxdhOhFMP1wtjRs_afxzdOw=.e8ff3265-5bd4-4cc7-998f-4e24fc3b945b@github.com>
Message-ID: <Gv0b1HQhr87sX2cVXqhMt0y2pMV-GAUdUrtH1a01Yhc=.e0861568-6b2c-47da-b4ee-79ad3a030697@github.com>

On Tue, 17 Oct 2023 11:37:11 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing review comments
>
> test/jdk/jdk/crac/ResetStartTimeTest.java line 40:
> 
>> 38:  * @library /test/lib
>> 39:  * @build SimpleTest
>> 40:  * @requires (os.family == "linux")
> 
> I think that if you use simengine the test is applicable to other platforms as well.

Done

> test/jdk/jdk/crac/ResetStartTimeTest.java line 75:
> 
>> 73:             assertLessThan(uptime1, WAIT_TIMEOUT);
>> 74:         } else {
>> 75:             assertLessThan(uptime0, uptime1);
> 
> If the C/R is really quick this should be <=

Done

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363474783
PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1363474550

From rmarchenko at openjdk.org  Wed Oct 18 09:08:41 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 09:08:41 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v3]
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <G6yqn2nbLhyW5OFwOIZ3jo3MCfUIbAh2kXa2pDcu9Bk=.3b10e41c-9a68-47af-9c2c-78d48223993a@github.com>

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Restoring file

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

Changes:
  - all: https://git.openjdk.org/crac/pull/130/files
  - new: https://git.openjdk.org/crac/pull/130/files/91913cb2..3daec256

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

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

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

From rvansa at openjdk.org  Wed Oct 18 18:59:12 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 18 Oct 2023 18:59:12 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v3]
In-Reply-To: <G6yqn2nbLhyW5OFwOIZ3jo3MCfUIbAh2kXa2pDcu9Bk=.3b10e41c-9a68-47af-9c2c-78d48223993a@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <G6yqn2nbLhyW5OFwOIZ3jo3MCfUIbAh2kXa2pDcu9Bk=.3b10e41c-9a68-47af-9c2c-78d48223993a@github.com>
Message-ID: <pdmnZsJXECFYRT3D3hRoJ90wcePvZhnK7y6v4uQVTbA=.59239135-f3e2-4e6a-a2fa-36727a6acccd@github.com>

On Wed, 18 Oct 2023 09:08:41 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> This change adds an opportunity reset both JVM's start time and uptime on restoring.
>> 
>> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
>> 
>> The flag is 'false' by default.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restoring file

LGTM in general, but the build is failing on some platforms with

/home/runner/work/crac/crac/src/hotspot/os/posix/crac_posix.cpp:44:14: error: incomplete type 'os::Posix' used in nested name specifier

and similar errors.

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

PR Review: https://git.openjdk.org/crac/pull/130#pullrequestreview-1685876624

From rmarchenko at openjdk.org  Wed Oct 18 19:09:16 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 18 Oct 2023 19:09:16 GMT
Subject: [crac] Integrated: Fixing crash on restore when user name is not set
In-Reply-To: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
References: <bqUebECjVZH2MIRWvlhfPNy9-KtES2PZz8auErqf7JM=.6d99f0b3-3e6e-492f-8414-efd6c3349952@github.com>
Message-ID: <uvRZtgnXmly2Z97auyqJqdSzLFxRHhS-rh8DyuybpNs=.9dca5c18-e656-4ba8-bc6a-758ffae59e68@github.com>

On Tue, 17 Oct 2023 08:53:02 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes a crash occuring during restore in a container when user name is not set.

This pull request has now been integrated.

Changeset: f0b2fcda
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/f0b2fcda193c532f1140479b085aedc93585cd88
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

Fixing crash on restore when user name is not set

Reviewed-by: rvansa

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

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

From rmarchenko at openjdk.org  Thu Oct 19 05:51:13 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 19 Oct 2023 05:51:13 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v4]
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <kuujXPBTbXAFez9l4SC5wn9v039qagDhLbjPXGBIyIg=.b3c4c6cb-78f2-4d4f-91ca-05602ee262d5@github.com>

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing builds

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

Changes:
  - all: https://git.openjdk.org/crac/pull/130/files
  - new: https://git.openjdk.org/crac/pull/130/files/3daec256..360bd03d

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

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

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

From rmarchenko at openjdk.org  Thu Oct 19 07:25:12 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 19 Oct 2023 07:25:12 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v5]
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing win32 build

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

Changes:
  - all: https://git.openjdk.org/crac/pull/130/files
  - new: https://git.openjdk.org/crac/pull/130/files/360bd03d..79c08f62

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

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

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

From rvansa at openjdk.org  Thu Oct 19 09:22:40 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 19 Oct 2023 09:22:40 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v5]
In-Reply-To: <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>
Message-ID: <51lNVtqyDzmCsr7DXDcvxBQ1YtcAKoMzCoYuiitKUzU=.29593240-9d4b-4cfa-83f1-dacc8a15f9a2@github.com>

On Thu, 19 Oct 2023 07:25:12 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> This change adds an opportunity reset both JVM's start time and uptime on restoring.
>> 
>> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
>> 
>> The flag is 'false' by default.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing win32 build

Marked as reviewed by rvansa (Committer).

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

PR Review: https://git.openjdk.org/crac/pull/130#pullrequestreview-1687161525

From rvansa at openjdk.org  Thu Oct 19 11:28:38 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 19 Oct 2023 11:28:38 GMT
Subject: [crac] RFR: Terminate restored process when criuengine restorewait
 exits
Message-ID: <-KSjntDhlfM5JvGVbp8MyfeW7XER7usE3i17FEufyyU=.ff7e9f88-b755-4172-b052-da8973e0af1f@github.com>

With criuengine the restored process gets restorewait process as its parent; scripts not expecting two processes might signal (e.g. terminate) the parent process but the actual restored process would get orphaned.

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

Commit messages:
 - Terminate restored process when criuengine restorewait exits

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

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

From akozlov at openjdk.org  Fri Oct 20 14:53:00 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Fri, 20 Oct 2023 14:53:00 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v7]
In-Reply-To: <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
 <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>
Message-ID: <rJ0DwYT8s8P0mwfRMRcGS2oidbfWwP9iJI_JWOrTfcg=.550d03c7-138e-47b1-83fa-23148cfd8217@github.com>

On Fri, 13 Oct 2023 15:39:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
>> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use hardcoded path

LGTM, thank you!

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

Marked as reviewed by akozlov (Lead).

PR Review: https://git.openjdk.org/crac/pull/119#pullrequestreview-1690219416

From abakhtin at openjdk.org  Fri Oct 20 18:22:00 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 20 Oct 2023 18:22:00 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v7]
In-Reply-To: <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
 <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>
Message-ID: <ECtH7lcMtNDI_Wda_gTWb3VuFX0vGddttO-0HvFgGCI=.5181fa13-1130-4449-a6a1-382b53c4bf48@github.com>

On Fri, 13 Oct 2023 15:39:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
>> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use hardcoded path

src/hotspot/os/linux/perfMemory_linux.hpp line 33:

> 31: 
> 32: public:
> 33:   static bool checkpoint(const char* checkpoint_path);

With the proposed changes you do not need the `checkpoint_path` parameter anymore.

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

PR Review Comment: https://git.openjdk.org/crac/pull/119#discussion_r1367362790

From rvansa at openjdk.org  Mon Oct 23 06:48:18 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 23 Oct 2023 06:48:18 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v8]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <Wu7LjdCvylowH1TxkvShKzE3dR6cWCIOPJyMcsolAJo=.3dae0de4-8b65-4250-b334-a5c94854a064@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  Remove unused parameter

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/ce6cb495..7157f39f

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

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

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

From rvansa at openjdk.org  Mon Oct 23 13:09:34 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 23 Oct 2023 13:09:34 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v9]
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <h-1XgF3dzovVHnmYCsw3tAVg6jVsEDKgZ0LM999G9no=.f7476d34-6335-4e3e-968c-e82b16289397@github.com>

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

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

  fixup

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

Changes:
  - all: https://git.openjdk.org/crac/pull/119/files
  - new: https://git.openjdk.org/crac/pull/119/files/7157f39f..1349d46c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=crac&pr=119&range=08
 - incr: https://webrevs.openjdk.org/?repo=crac&pr=119&range=07-08

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

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

From rvansa at openjdk.org  Mon Oct 23 13:25:34 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 23 Oct 2023 13:25:34 GMT
Subject: [crac] RFR: Put restored Java process on foreground instead of
 restorewait
Message-ID: <Bruw0Yr3ttRdxh32L43y-d0Nt5dDw2xZslfR0aewCEw=.dc376548-896d-4c04-be23-959466fa38d6@github.com>

Solves a scenario where we restore the process in background, `fg` it and then try to Ctrl+C interrupt it. 

The usefulness of this actually depends on https://github.com/CRaC/criu/pull/14

`criuengine` restorewait does not have tty on stdin/stdout/stderr, though one FD is open to tty; we have to find it.

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

Commit messages:
 - Put restored Java process on foreground instead of restorewait

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

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

From rvansa at openjdk.org  Mon Oct 23 15:34:01 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 23 Oct 2023 15:34:01 GMT
Subject: [crac] RFR: Drop perfdata and cppath [v7]
In-Reply-To: <ECtH7lcMtNDI_Wda_gTWb3VuFX0vGddttO-0HvFgGCI=.5181fa13-1130-4449-a6a1-382b53c4bf48@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
 <9h1quFhIzx-ceWjw6PzPIxUjRoKhml42KFu9TXSa32M=.0e55cf67-a0fd-466c-bcf5-3f34852cd4a7@github.com>
 <ECtH7lcMtNDI_Wda_gTWb3VuFX0vGddttO-0HvFgGCI=.5181fa13-1130-4449-a6a1-382b53c4bf48@github.com>
Message-ID: <YHXFDzRVHphWKQFF8IFJyZimjtklzfFQ1UgPKOzYJSQ=.dd770197-7988-4695-8f1e-858aa6c87684@github.com>

On Fri, 20 Oct 2023 18:19:02 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use hardcoded path
>
> src/hotspot/os/linux/perfMemory_linux.hpp line 33:
> 
>> 31: 
>> 32: public:
>> 33:   static bool checkpoint(const char* checkpoint_path);
> 
> With the proposed changes you do not need the `checkpoint_path` parameter anymore.

Thanks for noting that, updated.

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

PR Review Comment: https://git.openjdk.org/crac/pull/119#discussion_r1368878655

From rvansa at openjdk.org  Mon Oct 23 15:37:21 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 23 Oct 2023 15:37:21 GMT
Subject: [crac] Integrated: Drop perfdata and cppath
In-Reply-To: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
References: <ovHjYRuILTNW_gy3fbpbMS-Vh3pfUaBIRWEj-D-my-0=.e8308e38-dccf-40bd-9ac0-95bb26375549@github.com>
Message-ID: <ezcxyCJ8IIdY-TxmK_4g4DPtrPbX2EYozMyN-Eyv0bg=.5ba923f3-c763-47e9-b699-371c0203cd1d@github.com>

On Wed, 27 Sep 2023 20:40:53 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Storing PerfMemory contents into file might be fragile; if the file is corrupted (e.g. due to wrong permissions) JVM might receive SIGBUS when updating performance counters after restore.
> This commit provides alternate solution, moving the shared file-mapped memory into private anonymous memory during C/R.

This pull request has now been integrated.

Changeset: 84f170a3
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/84f170a30ac49552be5b479032e34cfa68a939cb
Stats:     279 lines in 7 files changed: 132 ins; 126 del; 21 mod

Drop perfdata and cppath

Reviewed-by: akozlov

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

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

From rmarchenko at openjdk.org  Tue Oct 24 07:22:59 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 24 Oct 2023 07:22:59 GMT
Subject: [crac] RFR: Put restored Java process on foreground instead of
 restorewait
In-Reply-To: <Bruw0Yr3ttRdxh32L43y-d0Nt5dDw2xZslfR0aewCEw=.dc376548-896d-4c04-be23-959466fa38d6@github.com>
References: <Bruw0Yr3ttRdxh32L43y-d0Nt5dDw2xZslfR0aewCEw=.dc376548-896d-4c04-be23-959466fa38d6@github.com>
Message-ID: <A3NpQFRnJagC2hzy7h5swBGrV1WFf10RXJNtSljF0uo=.88436612-1907-42a8-84bd-882ea04638ab@github.com>

On Mon, 23 Oct 2023 13:18:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Solves a scenario where we restore the process in background, `fg` it and then try to Ctrl+C interrupt it. 
> 
> The usefulness of this actually depends on https://github.com/CRaC/criu/pull/14
> 
> `criuengine` restorewait does not have tty on stdin/stdout/stderr, though one FD is open to tty; we have to find it.

src/java.base/unix/native/criuengine/criuengine.c line 391:

> 389:         int fd = atoi(dp->d_name);
> 390:         if (isatty(fd)) {
> 391:             g_tty_fd = fd;

Shouldn't we break here?

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

PR Review Comment: https://git.openjdk.org/crac/pull/133#discussion_r1369722656

From rmarchenko at openjdk.org  Tue Oct 24 14:17:11 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 24 Oct 2023 14:17:11 GMT
Subject: [crac] Integrated: Reset JVM start time and up time on restore
 (CRaCResetStartTime)
In-Reply-To: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
Message-ID: <YPSber5fii4dyi4f1424xcZ8KKJC2L6jN2gLmAs26fU=.1be1b89e-2b7b-44b2-ae50-8b4b5c8976e6@github.com>

On Tue, 17 Oct 2023 09:29:35 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change adds an opportunity reset both JVM's start time and uptime on restoring.
> 
> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
> 
> The flag is 'false' by default.

This pull request has now been integrated.

Changeset: 35d5bc4d
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/35d5bc4dc1f67f22dadec31cf8926bc8c2151593
Stats:     106 lines in 9 files changed: 104 ins; 2 del; 0 mod

Reset JVM start time and up time on restore (CRaCResetStartTime)

Reviewed-by: rvansa

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

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

From jkratochvil at openjdk.org  Wed Oct 25 15:17:09 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 25 Oct 2023 15:17:09 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU
Message-ID: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>

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

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

Commit messages:
 - Fix CPUFeatures crash on new->old CPU

Changes: https://git.openjdk.org/crac/pull/134/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=134&range=00
  Stats: 44 lines in 4 files changed: 33 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/crac/pull/134.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/134/head:pull/134

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

From akozlov at openjdk.org  Thu Oct 26 18:58:00 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Thu, 26 Oct 2023 18:58:00 GMT
Subject: [crac] RFR: Close files opened by Decoder before checkpoint [v2]
In-Reply-To: <6S30weJNZ0mIL0VExeOO1BQwq8xU9G5gZ_xiXM4mJ_E=.5e069f4b-789f-4fbf-a985-a13f270fd79a@github.com>
References: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
 <6S30weJNZ0mIL0VExeOO1BQwq8xU9G5gZ_xiXM4mJ_E=.5e069f4b-789f-4fbf-a985-a13f270fd79a@github.com>
Message-ID: <E44fMjTf-PcI7HniLJxI_weG7vzp6-hpopAD-m44mOE=.b2b8067d-7028-47be-942f-d0b4f4809b3b@github.com>

On Mon, 2 Oct 2023 18:59:40 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Native memory tracking needs to resolve some addresses for stack unwinding and the decoders keep some shared library files open as a cache. Since the decoder instances can be re-allocated anytime this fix just destroys them before a checkpoint.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assume error handler decoder is null during checkpoint

Marked as reviewed by akozlov (Lead).

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

PR Review: https://git.openjdk.org/crac/pull/116#pullrequestreview-1700426220

From akozlov at openjdk.org  Thu Oct 26 19:34:09 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Thu, 26 Oct 2023 19:34:09 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v5]
In-Reply-To: <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>
Message-ID: <4zHfAOtXP476tJjgt5IblV4uXi3BIGwtB-RrG8_vIw8=.6df06499-8110-41d5-ac46-363afba1e988@github.com>

On Thu, 19 Oct 2023 07:25:12 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> This change adds an opportunity reset both JVM's start time and uptime on restoring.
>> 
>> Resetting time may be performed with the new flag "-XX:+CRaCResetStartTime".
>> 
>> The flag is 'false' by default.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing win32 build

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

> 1999:   product(bool, CRaCResetStartTime, false, RESTORE_SETTABLE,                    \
> 2000:       "Reset JVM's start time and uptime on restore")                     \
> 2001:                                                                             \

Sorry for being late. Since we're evaluating providing the restore time via getUptime(), the option should be true by default, and be diagnostic.

Nit: the end of lines are not aligned.

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1373722320

From akozlov at openjdk.org  Thu Oct 26 19:35:07 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Thu, 26 Oct 2023 19:35:07 GMT
Subject: [crac] RFR: Persist memory in-JVM [v13]
In-Reply-To: <aRPexhYM6xDiJo3v3buKSUTCQoGtzSWVhRC48GYtGiw=.ccf48f13-4e83-47bb-8988-09871b8e072b@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
 <aRPexhYM6xDiJo3v3buKSUTCQoGtzSWVhRC48GYtGiw=.ccf48f13-4e83-47bb-8988-09871b8e072b@github.com>
Message-ID: <KCwM_BACTP_3l5iKFUGSjjPGaA14iAeX_iXX1Zb1USM=.f7caccda-1241-4bf4-971e-b83242db8319@github.com>

On Mon, 16 Oct 2023 11:59:13 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
>> 
>> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
>> 
>> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
>> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
>> 
>> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert changes not needed anymore in vm_version
>  - Windows build fix
>  - Refactored to fix OSX

Incomplete first round of review

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

> 479: 
> 480:   Atomic::add(&persist_waiters, 1);
> 481:   // From now on the code must not use stack variables!

Does it work in slowdebug? Suppose Atomic::add is not inlined and it creates the stack frame. Once the variable is decremented, but before the return, the stack may be unmapped already. Althought chances are not high. So this can in theory crash, right?

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

> 560:   // We cannot release this in after_threads_restored(), have to wait
> 561:   // until the last thread restores
> 562:   int dec = Atomic::sub(&persist_waiters, 1);

`Atomic::sub(&persist_waiters, 1)` is in the HAS_RSEQ ifdef. Apparently needs

...
#endif // HAS_RSEQ

int dec = Atomic::sub(&persist_waiters, 1);

#ifdef HAS_RSEQ
...


Or move the rseq_config memory freeing to `crac::after_threads_restored`, as a mirror of `crac::before_threads_persisted` which already spins on the `persist_waiters`.

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

> 361:   VM_Version::crac_restore_finalize();
> 362: 
> 363:   memory_restore();

memory_restore() does not gurantee not calling glibc extensively, so it may call unsupported CPU instruction before `VM_Version::crac_restore_finalize()` will have a chance to terminate the VM cleanly.

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

> 370:   if (CRPersistMemory) {
> 371:     // Before reinit_memory the code must not change memory layout, e.g. mmapping
> 372:     // or even malloc'ing anything (malloc running out of space could run short and allocate

Does the comment regarding malloc is valid in the current implementation? Is that the C lib malloc, or JVM's one, which we control and indeed should not use?

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

PR Review: https://git.openjdk.org/crac/pull/95#pullrequestreview-1700082007
PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1373459286
PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1373453376
PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1373476222
PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1373472920

From akozlov at openjdk.org  Thu Oct 26 19:41:08 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Thu, 26 Oct 2023 19:41:08 GMT
Subject: [crac] RFR: 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: <XsA-fmI5RifCW0_UZVuwb76EXdGaYb4vQEBi0W1Dcqs=.2ba22a4c-2624-4422-b56f-c3d2438a324b@github.com>

On Thu, 10 Aug 2023 16:02:32 GMT, null <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.

Would you mind rebasing the PR?

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

> 2285:         }
> 2286:       }
> 2287:       else if (strcmp(key, "jdk.internal.crac.mainArgs") == 0) {

Nit: please use One-True-Brace-Style https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#whitespace

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

PR Review: https://git.openjdk.org/crac/pull/101#pullrequestreview-1700515230
PR Review Comment: https://git.openjdk.org/crac/pull/101#discussion_r1373726907

From rmarchenko at openjdk.org  Thu Oct 26 19:41:13 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 26 Oct 2023 19:41:13 GMT
Subject: [crac] RFR: Reset JVM start time and up time on restore
 (CRaCResetStartTime) [v5]
In-Reply-To: <4zHfAOtXP476tJjgt5IblV4uXi3BIGwtB-RrG8_vIw8=.6df06499-8110-41d5-ac46-363afba1e988@github.com>
References: <IeN8LOmWLIMxm-hLQ-NaRHNlJNjxAgVZPqfAHPIHZZE=.a5312c1f-51c2-4259-a8da-7288c29d390b@github.com>
 <MC9l-Z6SpK6JarchbEf3Dg9U2_mEse8Swd0sQTjQMRg=.c7bf756b-95cc-4be2-ae3e-84233d776844@github.com>
 <4zHfAOtXP476tJjgt5IblV4uXi3BIGwtB-RrG8_vIw8=.6df06499-8110-41d5-ac46-363afba1e988@github.com>
Message-ID: <TbZ0GC4pbklHD8BKVE3QBFLvKKlseZUtdK9w0A40yz0=.172c55e1-170b-43b4-a42d-3b10185bb190@github.com>

On Thu, 26 Oct 2023 19:31:15 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing win32 build
>
> src/hotspot/share/runtime/globals.hpp line 2001:
> 
>> 1999:   product(bool, CRaCResetStartTime, false, RESTORE_SETTABLE,                    \
>> 2000:       "Reset JVM's start time and uptime on restore")                     \
>> 2001:                                                                             \
> 
> Sorry for being late. Since we're evaluating providing the restore time via getUptime(), the option should be true by default, and be diagnostic.
> 
> Nit: the end of lines are not aligned.

Ok, I will change it in a new PR

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

PR Review Comment: https://git.openjdk.org/crac/pull/130#discussion_r1373729413

From rvansa at openjdk.org  Fri Oct 27 08:07:11 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 27 Oct 2023 08:07:11 GMT
Subject: [crac] Integrated: Close files opened by Decoder before checkpoint
In-Reply-To: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
References: <6ZZkAT8Gst8w1pQ-y6FV8wm6Fystcs4Wpy0HzelKc-E=.2c029ec7-8ab7-4767-99a2-0feaab574510@github.com>
Message-ID: <kNmRqJSc0_3XTo4JcPyeeYmI6tMc9yWwQPI6ryiYfqs=.43b352ee-ef8b-41c1-96fa-7feeccbc280a@github.com>

On Mon, 25 Sep 2023 13:08:24 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> Native memory tracking needs to resolve some addresses for stack unwinding and the decoders keep some shared library files open as a cache. Since the decoder instances can be re-allocated anytime this fix just destroys them before a checkpoint.

This pull request has now been integrated.

Changeset: 1880603b
Author:    Radim Vansa <rvansa at openjdk.org>
URL:       https://git.openjdk.org/crac/commit/1880603bcb67e88818aa2d12ab8d23067f0fd4d9
Stats:     76 lines in 4 files changed: 76 ins; 0 del; 0 mod

Close files opened by Decoder before checkpoint

Reviewed-by: akozlov

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

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

From rmarchenko at openjdk.org  Fri Oct 27 10:26:08 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 27 Oct 2023 10:26:08 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults
Message-ID: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>

By the request in this comment https://github.com/openjdk/crac/pull/130/files#r1373722320

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

Commit messages:
 - Changing CRaCResetStartTime flag defaults

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

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

From rmarchenko at openjdk.org  Fri Oct 27 12:07:34 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 27 Oct 2023 12:07:34 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults [v2]
In-Reply-To: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
References: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
Message-ID: <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>

> By the request in this comment https://github.com/openjdk/crac/pull/130/files#r1373722320

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Forgot unlocking diag options

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

Changes:
  - all: https://git.openjdk.org/crac/pull/135/files
  - new: https://git.openjdk.org/crac/pull/135/files/b2ed68a2..eb2d3479

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

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

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

From rvansa at openjdk.org  Fri Oct 27 13:20:06 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 27 Oct 2023 13:20:06 GMT
Subject: [crac] RFR: 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: <B-I5Nvp982dL7fkJfOZbzmwVpfpAawiWRqFGVLIw5VM=.93090824-ed10-48f0-a71f-fae3dfd1895b@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

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

> 524:   // crac_restore_finalize() may terminate the process if we run on (older) CPU where glibc string functions may crash.
> 525:   // The flag is stored separately as all the code of this function below is difficult to implement without the string functions.
> 526:   bool IgnoreCPUFeatures_local;

In general, please use snake_case for local variables, even though it refers to VM option.

Rather than individual 'bits', can we make this at least part of the `header` structure? We could read that one without using any string functions, and then the variable-size rest of the data (which requires string funcs). The size being read can be part of the `header` structure rather than stat-ing the file.

Also, there is `read_all` function in `crac_linux.cpp` (I am moving that to a shared place in some PRs) that deals better with `::read` returning only partial result.

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

> 530:   }
> 531:   if (!IgnoreCPUFeatures_local) {
> 532:     VM_Version::crac_restore_finalize();

Is this function idempotent? It's called from `VM_Crac::doit()` as well (and it should be since reading the shm is optional), but could calling it twice cause any trouble?

src/hotspot/share/runtime/crac_structs.hpp line 225:

> 223:     assert(id > 0, "id is expected to be a PID and therefore > 0");
> 224:     char *d = _path;
> 225:     const char prefix[] = "/tmp/cracshm.";

Have you investigated any other option for transferring the data? While both `/tmp/` and `/dev/shm` are temp files, using `shm_open` looks like the go-to approach for sharing data. I dislike hardcoding the `/tmp` path, though it might be viable since perfMemory also has it hardcoded? In any case, this code is not linux-specific (this should be implemented in `crac_posix.cpp`, I suppose).

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

PR Review Comment: https://git.openjdk.org/crac/pull/134#discussion_r1374550270
PR Review Comment: https://git.openjdk.org/crac/pull/134#discussion_r1374553073
PR Review Comment: https://git.openjdk.org/crac/pull/134#discussion_r1374526685

From jkratochvil at openjdk.org  Fri Oct 27 13:33:04 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 27 Oct 2023 13:33:04 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU
In-Reply-To: <B-I5Nvp982dL7fkJfOZbzmwVpfpAawiWRqFGVLIw5VM=.93090824-ed10-48f0-a71f-fae3dfd1895b@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
 <B-I5Nvp982dL7fkJfOZbzmwVpfpAawiWRqFGVLIw5VM=.93090824-ed10-48f0-a71f-fae3dfd1895b@github.com>
Message-ID: <2YuvgXzzcgqS9X1RPbB_JRhAKDRm6CdLcUOfSgMNTeo=.5e6d236d-dc6e-46c7-8bb1-7c46753832d2@github.com>

On Fri, 27 Oct 2023 12:45:53 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> - reproducible on i7-1165G7 "qemu-kvm -cpu host" for a checkpoint and "qemu-kvm -cpu SandyBridge" for its restore
>
> src/hotspot/share/runtime/crac_structs.hpp line 225:
> 
>> 223:     assert(id > 0, "id is expected to be a PID and therefore > 0");
>> 224:     char *d = _path;
>> 225:     const char prefix[] = "/tmp/cracshm.";
> 
> Have you investigated any other option for transferring the data? While both `/tmp/` and `/dev/shm` are temp files, using `shm_open` looks like the go-to approach for sharing data. I dislike hardcoding the `/tmp` path, though it might be viable since perfMemory also has it hardcoded? In any case, this code is not linux-specific (this should be implemented in `crac_posix.cpp`, I suppose).

`shm_open` calls some string functions. So with the current (mis)design of CPUFeatures it cannot be used. One could call directly the syscall but that is too ugly. And then I do not see why to use SHM with the current design. One process creates the object, writes its data, closes the object. Second process opens the object, deletes the object, reads the data, closes the object. That is a normal usage of a tmp file. Shared memory has its use for some simultaneous data exchange but this is not the case so shared memory is overengineered. There is also limited amount of shared memory available so it is wasteful. Linuxes nowadays even have /tmp as tmpfs by default so even no disk operations are involved.
I agree "/tmp" should not be in this platform-independent file, I will fix that, thanks.
There are more portable functions for temporary files (`mktemp()` et al.) but these all use string functions.

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

PR Review Comment: https://git.openjdk.org/crac/pull/134#discussion_r1374589002

From jkratochvil at openjdk.org  Fri Oct 27 13:50:06 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 27 Oct 2023 13:50:06 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU
In-Reply-To: <B-I5Nvp982dL7fkJfOZbzmwVpfpAawiWRqFGVLIw5VM=.93090824-ed10-48f0-a71f-fae3dfd1895b@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
 <B-I5Nvp982dL7fkJfOZbzmwVpfpAawiWRqFGVLIw5VM=.93090824-ed10-48f0-a71f-fae3dfd1895b@github.com>
Message-ID: <fr0HG86P25Cq_QBil8XRWZmMitY5tl1duRA3DmjrzxI=.12b40feb-aad4-4fe3-8a1a-f76fd55ba39b@github.com>

On Fri, 27 Oct 2023 13:08:25 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> - reproducible on i7-1165G7 "qemu-kvm -cpu host" for a checkpoint and "qemu-kvm -cpu SandyBridge" for its restore
>
> src/hotspot/share/runtime/crac.cpp line 532:
> 
>> 530:   }
>> 531:   if (!IgnoreCPUFeatures_local) {
>> 532:     VM_Version::crac_restore_finalize();
> 
> Is this function idempotent? It's called from `VM_Crac::doit()` as well (and it should be since reading the shm is optional), but could calling it twice cause any trouble?

It is but it was just a luck. At least a comment there is wrong. I will improve it, thanks.

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

PR Review Comment: https://git.openjdk.org/crac/pull/134#discussion_r1374611831

From akozlov at openjdk.org  Fri Oct 27 14:36:59 2023
From: akozlov at openjdk.org (Anton Kozlov)
Date: Fri, 27 Oct 2023 14:36:59 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults [v2]
In-Reply-To: <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>
References: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
 <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>
Message-ID: <oEtMeXRxJkFOzm-J7T9ttehdzySp3NGI_YI_wvNyp_I=.ff11be03-cdb8-4670-9559-f9789c3d56fb@github.com>

On Fri, 27 Oct 2023 12:07:34 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> By the request in this comment https://github.com/openjdk/crac/pull/130/files#r1373722320
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot unlocking diag options

LGTM, thank you!

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

Marked as reviewed by akozlov (Lead).

PR Review: https://git.openjdk.org/crac/pull/135#pullrequestreview-1701947532

From rvansa at openjdk.org  Mon Oct 30 08:15:04 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 30 Oct 2023 08:15:04 GMT
Subject: [crac] RFR: Persist memory in-JVM [v13]
In-Reply-To: <aRPexhYM6xDiJo3v3buKSUTCQoGtzSWVhRC48GYtGiw=.ccf48f13-4e83-47bb-8988-09871b8e072b@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
 <aRPexhYM6xDiJo3v3buKSUTCQoGtzSWVhRC48GYtGiw=.ccf48f13-4e83-47bb-8988-09871b8e072b@github.com>
Message-ID: <pwx6glpdWRDRS4XjV6nl5MV-Fy2l9WsfEHiiy7rgHxw=.d503278c-1167-4977-b5b9-e5905fa0d73e@github.com>

On Mon, 16 Oct 2023 11:59:13 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
>> 
>> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
>> 
>> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
>> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
>> 
>> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert changes not needed anymore in vm_version
>  - Windows build fix
>  - Refactored to fix OSX

Closing this as we want to consider alternative approach, less invasive to the JVM.

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

PR Comment: https://git.openjdk.org/crac/pull/95#issuecomment-1784679006

From rvansa at openjdk.org  Mon Oct 30 08:15:04 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 30 Oct 2023 08:15:04 GMT
Subject: [crac] Withdrawn: Persist memory in-JVM
In-Reply-To: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
References: <pJIQC--pm9qmPfUL9HPBZO5pNXSkxVMWxi0xx2xsdRQ=.da738a7f-cbb9-46c7-bb0f-39932b44d0bd@github.com>
Message-ID: <Wkja1OaTCVZC8e7NTWCKbu2CgU0FwM4x1aKyJK404QY=.2cb525fd-a7b6-4558-8beb-a5e3c866d766@github.com>

On Fri, 28 Jul 2023 17:07:22 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This is a WIP for persisting various portions of JVM memory from within the process, rather than leaving that up to C/R engine (such as CRIU). In the future this will enable us to optimize loading (theoretically leading to faster startup), compress and encrypt the data.
> 
> At this moment the implementation of persisting thread stacks is in proof-of-concept shape, ~especially waking up the primordial thread includes some hacks. This could be improved by using a custom (global, ideally robust) futex instead of the internal futex used by `pthread_join`.~ Fix already implemented.
> 
> ~One of the concerns related to thread stacks is rseq used by glibc; without disabling this CRIU would attempt to 'fix' the rseqs (see `fixup_thread_rseq`) and touch the unmapped memory. CRIU uses special ptrace commands to check the status; I am not aware if it is possible to access this information from within the process using any public API.~ Solved. The JVM forks and the child ptraces JVM, recording the rseq info. Once we have the we can unregister the rseq before checkpoint and register it afterwards (here we have the advantage that we know the threads won't be in any critical section as we're in a safepoint).
> ~Currently this works with `/proc/sys/kernel/yama/ptrace_scope` set to `0`; we should make it work with `1` (default), too.~ Fixed.
> 
> Regarding persistence implementation, currently we store the memory in multiple files; first block (page-size aligned) contains some validation data and index of memory address - file offsets. The way this is implemented requires the size of index to be known before dumping memory. It might be more convenient (and portable for e.g. network-based storage) to use single file, and either keep the index in the 'fundamental' memory (C heap), put it at the end of file or to another index file.

This pull request has been closed without being integrated.

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

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

From rvansa at openjdk.org  Mon Oct 30 08:17:07 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 30 Oct 2023 08:17:07 GMT
Subject: [crac] Withdrawn: If std descriptor is bound with regular file,
 redirect it to pseudo terminal before the checkpoint
In-Reply-To: <YWhzIPMLufh5cj8EDLt0ISvpZGNInt70FYLvSkx-Rfk=.f9433b57-30ec-4d11-a19d-d8bd7f18a0ff@github.com>
References: <YWhzIPMLufh5cj8EDLt0ISvpZGNInt70FYLvSkx-Rfk=.f9433b57-30ec-4d11-a19d-d8bd7f18a0ff@github.com>
Message-ID: <iurCtZHhCPN9q1c-kHAJ3jQV1Yej4gxawBfB0Yi0nEo=.301c11d8-c1cf-4cb0-9ffb-93e27dd33a37@github.com>

On Fri, 17 Jun 2022 14:22:37 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

> CRIU restore fail after Checkpoint stdout to file.
> Redirecting a stdout to the pipeline doesn't break the restore. 
> 
> A proposed approach forces the close of stdout, stdin, and stderr file descriptors if they are redirected to the files, on checkpoint resources verification.

This pull request has been closed without being integrated.

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

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

From jkratochvil at openjdk.org  Mon Oct 30 13:26:19 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 30 Oct 2023 13:26:19 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v2]
In-Reply-To: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
Message-ID: <_1A6n-o1iH57xmfl4YtnkSRvVRkgQ-DsHJR_kQJ5h5k=.2385876d-f1ec-4c41-8371-a29ab4d2caa8@github.com>

> - 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 four additional commits since the last revision:

 - Make _ignore_cpu_features a tri-state.
 - Fix up double call of VM_Version::crac_restore_finalize().
    - found by Randim Vansa
 - Move IgnoreCPUFeatures_local into the header.
    - suggested by Radim Vansa
 - Move CracSHM::_prefix to crac_posix.cpp
    - suggested by Radim Vansa

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

Changes:
  - all: https://git.openjdk.org/crac/pull/134/files
  - new: https://git.openjdk.org/crac/pull/134/files/d26f972a..f9470978

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

  Stats: 56 lines in 5 files changed: 24 ins; 15 del; 17 mod
  Patch: https://git.openjdk.org/crac/pull/134.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/134/head:pull/134

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

From jkratochvil at openjdk.org  Mon Oct 30 15:17:58 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 30 Oct 2023 15:17:58 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v3]
In-Reply-To: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
Message-ID: <-i-OQDAsVq682vmEs5n7XOiziSCKUlwYmq_Vseu5sWE=.ceff798d-d630-47cc-a22b-9d3d5edf9fb6@github.com>

> - 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 non-x86* compilation

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

Changes:
  - all: https://git.openjdk.org/crac/pull/134/files
  - new: https://git.openjdk.org/crac/pull/134/files/f9470978..f66a71ae

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

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

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

From jkratochvil at openjdk.org  Mon Oct 30 15:40:53 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 30 Oct 2023 15:40:53 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v4]
In-Reply-To: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
Message-ID: <nZDwCT_0eQA15tfE8RwWS-SRDfJ9Z0Om_DQbM4FVjQI=.7efceecc-e13c-4865-b571-41a3ae730a25@github.com>

> - 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 MSVC compilation

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

Changes:
  - all: https://git.openjdk.org/crac/pull/134/files
  - new: https://git.openjdk.org/crac/pull/134/files/f66a71ae..1b24fed5

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

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

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

From jkratochvil at openjdk.org  Tue Oct 31 00:13:23 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 00:13:23 GMT
Subject: [crac] RFR: Fix CPUFeatures crash on new->old CPU [v5]
In-Reply-To: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
References: <mkFOY1m6tVQjOXY0MZieOrvTJDaM7cqT7I5H64NJhYc=.9f3f38e0-862d-44e6-a38b-ce0c41aa1db8@github.com>
Message-ID: <2i-sgzbKFF7PDRW4_LAJsYGG1dlEZNPtHTDT28pDkBQ=.5dc6b33d-375e-4c61-b497-7e9c8318d7fd@github.com>

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

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

Changes:
  - all: https://git.openjdk.org/crac/pull/134/files
  - new: https://git.openjdk.org/crac/pull/134/files/1b24fed5..c1983089

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

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

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

From jkratochvil at openjdk.org  Tue Oct 31 07:03:25 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 07:03:25 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally
Message-ID: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>

Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
Fix compilation failures.

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

Commit messages:
 - Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code unconditionally

Changes: https://git.openjdk.org/crac/pull/136/files
 Webrev: https://webrevs.openjdk.org/?repo=crac&pr=136&range=00
  Stats: 91 lines in 1 file changed: 12 ins; 13 del; 66 mod
  Patch: https://git.openjdk.org/crac/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/136/head:pull/136

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

From rvansa at openjdk.org  Tue Oct 31 07:03:28 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 31 Oct 2023 07:03:28 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally
In-Reply-To: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
Message-ID: <sYHIPwmDXTTStQl8LUaEdK4lQHMzIXFSnFj9Vzo6V_g=.d84ff666-7f16-4c9c-a056-f130a23863c3@github.com>

On Tue, 31 Oct 2023 06:28:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
> Fix compilation failures.

While I like the certainty that the code is always compilable, I wonder if handling optional features like this (using macros in conditions) is a pattern that is used elsewhere in the JDK?

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

> 854: }
> 855: 
> 856: //#if INCLUDE_LD_SO_LIST_DIAGNOSTICS

Please remove commented out code.

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

> 942:   const char *env = getenv(TUNABLES_NAME);
> 943:   if (env && strcmp(env, env_val) == 0) {
> 944:     if (!INCLUDE_CPU_FEATURE_ACTIVE && !INCLUDE_LD_SO_LIST_DIAGNOSTICS) {

Have you tested compilation with these disabled? Looks to me like the compiler could complain about unreachable code when the condition is always false...

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

PR Review: https://git.openjdk.org/crac/pull/136#pullrequestreview-1705554187
PR Review Comment: https://git.openjdk.org/crac/pull/136#discussion_r1377123401
PR Review Comment: https://git.openjdk.org/crac/pull/136#discussion_r1377126065

From jkratochvil at openjdk.org  Tue Oct 31 07:07:58 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 07:07:58 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally
In-Reply-To: <sYHIPwmDXTTStQl8LUaEdK4lQHMzIXFSnFj9Vzo6V_g=.d84ff666-7f16-4c9c-a056-f130a23863c3@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
 <sYHIPwmDXTTStQl8LUaEdK4lQHMzIXFSnFj9Vzo6V_g=.d84ff666-7f16-4c9c-a056-f130a23863c3@github.com>
Message-ID: <-CVBLLzC2LgrvDHYxmrcMW7PbQ3h599J1HraCYvVIqs=.6556bc9f-f743-4195-8c07-1a216be6bb64@github.com>

On Tue, 31 Oct 2023 06:52:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
>> Fix compilation failures.
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 856:
> 
>> 854: }
>> 855: 
>> 856: //#if INCLUDE_LD_SO_LIST_DIAGNOSTICS
> 
> Please remove commented out code.

I wanted to indicate this function is used only for `INCLUDE_LD_SO_LIST_DIAGNOSTICS`. I can also put there a full sentence.

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

PR Review Comment: https://git.openjdk.org/crac/pull/136#discussion_r1377132708

From rvansa at openjdk.org  Tue Oct 31 07:14:57 2023
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 31 Oct 2023 07:14:57 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults [v2]
In-Reply-To: <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>
References: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
 <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>
Message-ID: <YSF_sBnXEWKFRqBj6dpMKZR2_3iqYn7KMV6Sstry80o=.e71931b8-d6c7-49b4-bc19-f9ce32c7feac@github.com>

On Fri, 27 Oct 2023 12:07:34 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> By the request in this comment https://github.com/openjdk/crac/pull/130/files#r1373722320
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot unlocking diag options

@wkia Sorry to chime in rather late, but now it seems that this flag can be set only before checkpoint; why is that? Is there an issue in making this both diagnostic and restore-settable? (I guess that `UnlockDiagnosticOptions` might need to become restore-settable, too, but I don't see an issue with that)

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

PR Comment: https://git.openjdk.org/crac/pull/135#issuecomment-1786589857

From jkratochvil at openjdk.org  Tue Oct 31 07:40:22 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 07:40:22 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally [v2]
In-Reply-To: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
Message-ID: <WMTr3f0b3KaXmzIXnlMmA36lsrJVfDZJ_j6r4dt5h-c=.4609d279-4b0e-45dd-8064-8ec9a131bcfd@github.com>

> Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
> Fix compilation failures.

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

  Fix compilation errors during all the 3 configurations:
    #undef INCLUDE_CPU_FEATURE_ACTIVE
    #undef INCLUDE_LD_SO_LIST_DIAGNOSTICS
    #define INCLUDE_CPU_FEATURE_ACTIVE 0/1
    #define INCLUDE_LD_SO_LIST_DIAGNOSTICS 0/1
     - but never 1 for both

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

Changes:
  - all: https://git.openjdk.org/crac/pull/136/files
  - new: https://git.openjdk.org/crac/pull/136/files/0b4f6692..c1769a92

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

  Stats: 69 lines in 2 files changed: 22 ins; 27 del; 20 mod
  Patch: https://git.openjdk.org/crac/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/crac.git pull/136/head:pull/136

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

From jkratochvil at openjdk.org  Tue Oct 31 07:40:25 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 07:40:25 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally [v2]
In-Reply-To: <sYHIPwmDXTTStQl8LUaEdK4lQHMzIXFSnFj9Vzo6V_g=.d84ff666-7f16-4c9c-a056-f130a23863c3@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
 <sYHIPwmDXTTStQl8LUaEdK4lQHMzIXFSnFj9Vzo6V_g=.d84ff666-7f16-4c9c-a056-f130a23863c3@github.com>
Message-ID: <DrKAgTkoFikW_i5F5XE8nIQJdmE9n49btZypgztzeD8=.dedbf16d-8ddc-4297-9f2e-d75ae93f2014@github.com>

On Tue, 31 Oct 2023 06:56:41 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 compilation errors during all the 3 configurations:
>>     #undef INCLUDE_CPU_FEATURE_ACTIVE
>>     #undef INCLUDE_LD_SO_LIST_DIAGNOSTICS
>>     #define INCLUDE_CPU_FEATURE_ACTIVE 0/1
>>     #define INCLUDE_LD_SO_LIST_DIAGNOSTICS 0/1
>>      - but never 1 for both
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 944:
> 
>> 942:   const char *env = getenv(TUNABLES_NAME);
>> 943:   if (env && strcmp(env, env_val) == 0) {
>> 944:     if (!INCLUDE_CPU_FEATURE_ACTIVE && !INCLUDE_LD_SO_LIST_DIAGNOSTICS) {
> 
> Have you tested compilation with these disabled? Looks to me like the compiler could complain about unreachable code when the condition is always false...

I have tried all the 3 compilation cases only now. I do not see such compiler warnings (although different compilations and compilers produce different warnings) but I could fix some other problems. Which will make me update #112.

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

PR Review Comment: https://git.openjdk.org/crac/pull/136#discussion_r1377162882

From jkratochvil at openjdk.org  Tue Oct 31 08:02:19 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 08:02:19 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally [v3]
In-Reply-To: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
Message-ID: <tEA3GTE5YMkQXGt5NEZ8uBYbnFIfSDtiqcTnsBXBidM=.b422411d-fe8a-4216-863c-26fbb067d80d@github.com>

> Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
> Fix compilation failures.

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

  More compilation cases fixes

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

Changes:
  - all: https://git.openjdk.org/crac/pull/136/files
  - new: https://git.openjdk.org/crac/pull/136/files/c1769a92..f628f71f

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

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

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

From rmarchenko at openjdk.org  Tue Oct 31 08:44:00 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 31 Oct 2023 08:44:00 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults [v2]
In-Reply-To: <YSF_sBnXEWKFRqBj6dpMKZR2_3iqYn7KMV6Sstry80o=.e71931b8-d6c7-49b4-bc19-f9ce32c7feac@github.com>
References: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
 <6RRWH6xcx99cF_4uMeHFsaWrq2USJNU7g4KWnwiDyfc=.fc7edd6a-231e-47a4-92d6-f899093e516e@github.com>
 <YSF_sBnXEWKFRqBj6dpMKZR2_3iqYn7KMV6Sstry80o=.e71931b8-d6c7-49b4-bc19-f9ce32c7feac@github.com>
Message-ID: <u0JfCD0kZ8AzXYvtv05WuHOdoFaTa2S-NDOkPqKrMlM=.cc85b0f3-9d9d-4732-b1cb-b67ef99cbae5@github.com>

On Tue, 31 Oct 2023 07:12:07 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Forgot unlocking diag options
>
> @wkia Sorry to chime in rather late, but now it seems that this flag can be set only before checkpoint; why is that? Is there an issue in making this both diagnostic and restore-settable? (I guess that `UnlockDiagnosticOptions` might need to become restore-settable, too, but I don't see an issue with that)

@rvansa You're right, thanks. 
Need to be reviewed by @AntonKozlov also.  Should we change `UnlockDiagnosticOptions` to `RESTORE_SETTABLE` as well? If not,  `CRaCResetStartTime` will be available on checkpoint only as a diagnostic option.

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

PR Comment: https://git.openjdk.org/crac/pull/135#issuecomment-1786752477

From rmarchenko at openjdk.org  Tue Oct 31 09:19:23 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 31 Oct 2023 09:19:23 GMT
Subject: [crac] RFR: Changing CRaCResetStartTime flag defaults [v3]
In-Reply-To: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
References: <ZgCYriymvKE84c2SU-9iVmlLehsZNDvIPVJ7Jch4CAQ=.2d3f8b64-0bd2-47ab-a270-dc281d995dc7@github.com>
Message-ID: <tQ0rU7ayXQ6eZSKJOv8cy3_TIMQBJ7HAyOIEzfqmrJ0=.a9c32828-ccba-4c4f-8aa9-6ec97b038d62@github.com>

> By the request in this comment https://github.com/openjdk/crac/pull/130/files#r1373722320

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing review comments

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

Changes:
  - all: https://git.openjdk.org/crac/pull/135/files
  - new: https://git.openjdk.org/crac/pull/135/files/eb2d3479..69e18582

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

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

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

From jkratochvil at openjdk.org  Tue Oct 31 10:23:14 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 31 Oct 2023 10:23:14 GMT
Subject: [crac] RFR: Compile all the INCLUDE_LD_SO_LIST_DIAGNOSTICS code
 unconditionally [v4]
In-Reply-To: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
References: <2mqoLQRftHj0yP4KYkOY-G6s1zFq2pu4ozfB5zpBAq8=.b935db48-4bae-48c1-84bd-841486ab121c@github.com>
Message-ID: <Ce46hArjq6_P4AIPKiQUvXf5ZnKln41EbSgmT1zUfGc=.bd33b7e3-a1dd-4817-be67-258eb0b2f11d@github.com>

> Make INCLUDE_LD_SO_LIST_DIAGNOSTICS an `if` conditional instead of a `#if` one.
> Fix compilation failures.

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - Fix compilation on non-Linux OSes
 - Fix more compilation problems

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

Changes:
  - all: https://git.openjdk.org/crac/pull/136/files
  - new: https://git.openjdk.org/crac/pull/136/files/f628f71f..ac5191c6

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

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

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