[crac] RFR: 8350845: [CRaC] Support C/R engines in form of a library [v7]

[Timofei Pushkin]

On Thu, 6 Mar 2025 08:02:28 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> Adds support for C/R engines implemented in form of dynamic libraries.
>> 
>> In the proposed API the engine controls the set of the configurable options — they are mainly passed by the user via the new `CRaCEngineOptions` VM option, but some may also be passed by the VM. Other VM and/or engine implementations may extend the API via "extensions".
>> 
>> The JVM is supposed to know what configuration options and API extensions are supported by calling `can_configure` and `get_extension`.
>> 
>> The user is supposed to know which options they can pass by asking the engine with `-XX:CRaCEngineOptions=help` (support for this is engine-dependent). Example of how this looks for bundled engines:
>> 
>> $ java -XX:CRaCEngineOptions=help
>> crexec - pseudo-CRaC-engine used to relay data from JVM to a "real" engine implemented as an executable (instead of a library). The engine executable is expected to have CRaC-CRIU-like CLI. Support of the configuration options also depends on the engine executable.
>> 
>> Configuration options:
>> * keep_running=<true/false> (default: false) - keep the process running after the checkpoint or kill it.
>> * direct_map=<true/false> (default: false) - on restore, map process data directly from saved files. This may speedup the restore but the resulting process will not be the same as before the checkpoint.
>> * args=<string> (default: "") - free space-separated arguments passed directly to the engine executable, e.g. "--arg1 --arg2 --arg3".
>> 
>> 
>> Notable related changes included in the patch:
>> - The ability to pass arguments to C/R engine was removed from `CRaCEngine` because it can now be implemented through `CRaCEngineOptions`. E.g. `-XX:CRaCEngine=criu,--verbose` is now `-XX:CRaCEngine=criu -XX:CRaCEngineOptions=args=--verbose`.
>> - `CRaCEngine` (as well as the new `CRaCEngineOptions`) VM Option is now not updated in the restored VM. This seems more correct because engine path and options will very likely differ on restore and on checkpoint, so it is not obvious how to combine them — just replacing won't always work. Until now the updates were ignored by the CRaC implementation anyway, so this should only be visible by inspecting the options through JMX.
>> - `CRaCRestoreFrom` is now considered set (and thus an attempt to restore is made) only if it is set to a non-empty value, i.e. `-XX:CRaCRestoreFrom=""` won't trigger a (failing) restore attempt anymore. This is to be consistent with how `-XX:CRaCCheckpointTo=""` does not trigger a chec...
>
> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix Windows debug build
>  - Minor improvements

Regarding [the problem with Windows debug builds](https://github.com/TimPushkin/crac/actions/runs/13674162120/job/38230839206#step:10:2700), it looks like Windows debug build [tries to export all symbols](https://github.com/openjdk/crac/blob/884d0746b168550f13bdc687b1d96d468aec4411/make/hotspot/lib/CompileJvm.gmk#L235) which don't have "type_info" or "lambda" in their name regardless of whether they have external or internal linkage. Not sure for what purpose (for testing/debugging?).

In my particular case, if the hashing/equality functions I've introduced have internal linkage, the hashtable template instantiation has internal linkage too and linker fails to export it. If the functions have external linkage, the template instantiation has external linkage too and everything is fine. This is the workaround I've chosen (also put them in a class just to have a "name space" for them).

Alternatively, if I add "type_info" or "lambda" to the name of any of the functions the resulting hashtable template instantiation symbol will have this substring in its name and thus it will be filtered from the export list by the build system, the error will not occur (and the symbols in question will have internal linkage). This seems fragile so I've decided against it.

In release builds this doesn't happen probably because [the symbol table used to construct the export list](https://learn.microsoft.com/en-us/cpp/build/reference/symbols) is only filled for debug builds.

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

PR Comment: https://git.openjdk.org/crac/pull/207#issuecomment-2703196695