[crac] RFR: 8353243: [CRaC] Show all options in engine help

[Timofei Pushkin]

On Wed, 2 Apr 2025 14:00:49 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> C/R engines are now advised to list all options in `configuration_doc`. If JVM does not let users to control some options it states that in the engine help message.
>> 
>> crexec now documents internal options, such as `image_location` and `exec_location`, in its doc message.
>> 
>> This is how crexec's help looks with this change:
>> 
>> $ 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:
>> * image_location=<path> (no default) - path to a directory with checkpoint/restore files.
>> * exec_location=<path> (no default) - path to the engine executable.
>> * keep_running=<true/false> (default: false) - keep the process running after the checkpoint or kill it.
>> * direct_map=<true/false> (default: true) - 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".
>> 
>> Configuration options controlled by the JVM: image_location exec_location
>
> src/hotspot/share/runtime/crac_engine.cpp line 415:
> 
>> 413:   }
>> 414: 
>> 415:   if (strcmp(id, "crexec") == 0) {
> 
> I don't think you need the `crexec` check here. I would also drop the logging parts, unlikely to be useful in the practice.

It may be an external C/R engine with `exec_location` option — JVM won't block the user from using this option so it shouldn't be included here. It is possible for this engine to also be named "crexec" so this check is not fully robust (it would be more robust to record that we've loaded _our crexec_) but I've decided this is a decent balance between robustness and code simplicity.

Regarding the logs, agree, I'll remove them.

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

PR Review Comment: https://git.openjdk.org/crac/pull/220#discussion_r2025002510