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

[mazhen]

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

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

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

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

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

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

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

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

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

Hi @rvansa ,

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

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

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

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

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