When -XX:+CRaCIgnoreRestoreIfUnavailable is used it is expected to also specify a main class and its arguments so that if the restoration fails the normal startup process could use them.
However with the current implementation, if the restoration succeeds it will use these arguments to try to start a new main. Since it is rare to have the same arguments on checkpoint and on restore, such behavior is usually unwanted and leads to errors after restore.
Thus it is proposed to ignore the new arguments when `CRaCIgnoreRestoreIfUnavailable` is set to true on restore.
In the future we may add a new option, e.g. `CRaCRestoreWithNewMain`, and change the behavior to only use new arguments when this option is true. This would allow using new arguments on restore even with `CRaCIgnoreRestoreIfUnavailable`. But since that is not expected to be widely needed, it is out of the scope of this task.
However with the current implementation, if the restoration succeeds it will use these arguments to try to start a new main. Since it is rare to have the same arguments on checkpoint and on restore, such behavior is usually unwanted and leads to errors after restore.
Thus it is proposed to ignore the new arguments when `CRaCIgnoreRestoreIfUnavailable` is set to true on restore.
In the future we may add a new option, e.g. `CRaCRestoreWithNewMain`, and change the behavior to only use new arguments when this option is true. This would allow using new arguments on restore even with `CRaCIgnoreRestoreIfUnavailable`. But since that is not expected to be widely needed, it is out of the scope of this task.
- links to
-
Review(crac) openjdk/crac/261