[crac] RFR: Support updating MANAGEABLE JVM options during restore

[Radim Vansa]

On Fri, 28 Apr 2023 14:56:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> When a JVM option is MANAGEABLE it can be set at any time during runtime, therefore it is safe to change it during the restore operation. Rather than silently ignoring JVM options passed along with -XX:CRaCRestoreFrom we send them to the restored process and either update or print a warning if given option cannot be changed.
>
> src/hotspot/os/linux/os_linux.cpp line 6557:
> 
>> 6555:   ::_restore_start_counter = hdr->_restore_counter;
>> 6556: 
>> 6557:   for (int i = 0; i < hdr->_nflags; i++) {
> 
> This check can be done in the "bootstrap" process (the one that execs to CREngine): just to avoid restoring and finding out the problem. See the other comment about producing the error.

Makes sense, I'll turn those into errors. I should probably also check the presence of `-jar` and `-cp`/`--classpath` and produce a nice explanation; otherwise the code would interpret those as the new main class and its arguments.

> src/hotspot/share/runtime/globals.hpp line 2096:
> 
>> 2094:   /* It does not make sense to change this flag in runtime but we'll tag */ \
>> 2095:   /* it MANAGEABLE to prevent warnings when setting this on restore. */     \
>> 2096:   product(ccstr, CRaCRestoreFrom, NULL, MANAGEABLE,                         \
> 
> This is an example why we want "can be set on restore" (RESTOREBLE?) flag. So MANAGABLE will be implying RESTORABLE, but not every RESTORABLE will be MANAGEABLE.

Below we see that `CRaCIgnoredFileDescriptors` is RESTORABLE (I would rather use SET_ON_RESTORE as all flags are restored at its previous value) but not MANAGEABLE, so that's not perfect either. The reason why I rather stayed on MANAGEABLE was to prevent changing every `MANAGEABLE` to `MANAGEABLE | SET_ON_RESTORE`, that would complicate any backport from mainline.

I can do the SET_ON_RESTORE (as superset of MANAGEABLE) but I don't think that the few exceptions that could be rather documented by a few lines of comment really deserve a separate flag.

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

PR Review Comment: https://git.openjdk.org/crac/pull/61#discussion_r1182193699
PR Review Comment: https://git.openjdk.org/crac/pull/61#discussion_r1182191415