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

Timofei Pushkin tpushkin at openjdk.org
Mon Apr 7 08:51:12 UTC 2025


On Mon, 7 Apr 2025 08:34:42 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> 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.
>
> Let's ignore the theoretical ambiguity for `crexec`...
> 
>> 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.
> 
> I do not get the message. If an external engine supports that option, then JVM should provide the information (maybe the engine wants to load some shared library that is in the lib directory?). It shouldn't treat `our crexec` differently than any external engine.

I treat `exec_location` and the whole `crexec` as a JVM's implementation detail: if JVM determines that the engine passed to `CRaCEngine` is an executable then it uses `crexec` and passes it the location of the real engine via `exec_location` — in no other case `exec_location` is used.

So no other engine should be able to access this usage of `exec_location`:
- if the engine is a library, JVM won't use `exec_location` at all (and it will allow the user to use an option with such name)
- if the engine is an executable, JVM will pass `exec_location` to `crexec` but it won't be passed to the engine executable itself (the user can use `args` to pass arguments to the executable)

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

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


More information about the crac-dev mailing list