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

[Radim Vansa]

On Mon, 7 Apr 2025 08:48:18 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> 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)

Despite `crexec` is part of JVM codebase and it allows JVM to use executable-based engine implementations, I don't consider it a part of JVM; the separation line should be drawn at CRE API level. So it should not be a "JVM's implementation detail".

In the first version of the API it was called 'library_path`: informing the engine about a place where it should load other executables/libraries from. In fact, it is non-trivial to programmatically figure out from within a shared library was loaded from (if e.g. it needs to load some extra resource that should be in the same directory) so it might be useful.

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

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