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

Radim Vansa rvansa at openjdk.org
Mon Apr 7 15:12:22 UTC 2025


On Mon, 7 Apr 2025 13:03:03 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>>> I might have focused too much on this being "handy", but my main objective was to not have any code in JVM that would treat different engines differently.
>> 
>> Well, JVM will treat `crexec` somewhat specially anyway because this is the only engine that is not requested by the user directly but rather by the JVM (when it finds that the user requested an executable engine), but I get it that you want to reduce such special handling as much as possible.
>> 
>>> Btw. there's third option: we could use the dladdr/GetModuleFileName in crexec and drop exec_location completely.
>> 
>> Through `dladdr`/`GetModuleFileName` crexec can find where it is located, i.e. this is indeed a substitution for `library_path`. But we'll still need to pass the location of the engine executable (otherwise crexec won't know what exactly to call), and it can be any user-provided absolute path, not only `lib` within JDK installation. The most convenient way would be to use an option which leads us to `exec_location` again.
>
>> Anyway this doesn't have to be exhaustive: there might be other option (JVM wouldn't know about) to hint about some other path.
> 
> If JVM doesn't know about it then it should be passed by the user directly: `-XX:CRaCEngine=crexec -XX:CRaCEngineOptions=engine=criu` — this would be somewhat inconvenient from UX perspective

> But we'll still need to pass the location of the engine executable (otherwise crexec won't know what exactly to call), and it can be any user-provided absolute path,

I had to re-read the code again - my understanding of the option meaning was really wrong, it is passing the resolved location of the executable. So now I understand your argument, and the "third option" is really not viable. And I have to withdraw the argument that it's useful to external implementations; in fact it's set to `nullptr` if `CRaCEngine` does not refer to a shared library.

>> Anyway this doesn't have to be exhaustive: there might be other option (JVM wouldn't know about) to hint about some other path.

> If JVM doesn't know about it then it should be passed by the user directly: -XX:CRaCEngine=crexec -XX:CRaCEngineOptions=engine=criu — this would be somewhat inconvenient from UX perspective

Due to my confusion we were talking about two different things. Let's imagine a hypotetical engine `foobar`; this engine would live in `$JAVA_HOME/lib/libfoobar.so` and be invoked with `-XX:CRaCEngine=foobar`.
* if the engine would for some reason need load `libjsig.so` it would need the `library_path`
* if the engine would need to execute binary `foobar-tool` it could likely refer to the same directory through `dladdr`
* if the engine needs to load `libzip.so` from a non-standard location, you would pass `-XX:CRaCEngineOptions=foobar.lib_dir=/opt/myzip` <- by non-exhaustive I meant that you could do this rather than lookup in engine's directory or `$JAVA_HOME/lib`

In any case, I would suggest to have a fixed list of reserved CRE options, and as you noted, omit engine-specific handling as much as possible. Let's keep things as simple as these can be.

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

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


More information about the crac-dev mailing list