[crac] RFR: Provide arguments for restore [v5]

[Anton Kozlov]

On Fri, 1 Apr 2022 16:16:37 GMT, Ashutosh Mehra <duke at openjdk.java.net> wrote:

> I am looking at the need for new arguments as no different than the post-restore adjustments that the application may have to do. 

Indeed, I was thinking about the same, and now I realized there is a subtle difference. There are a lot Resources, if each of them may process arguments, how would they interpret them? E.g. does `-f` parameter means the same thing for all resources in the system? If not, how to specify a parameter is designated to a particular Resource? Technically nothing prevents two Resources to assume they are in position to process arguments.

Resources are required when an object of a class may require checkpoint/restore notification, but for the program the existence of the object is not clear (the object may not be created, the object may be GCed, the class may not be loaded at all in this program configuration). If it's possible to program without Resource's, it's better than with them.

BTW, the JavaCompilerCRaC object on line 44 won't survive GC, so it won't be notified.
https://github.com/ashu-mehra/crac/commit/3360123f4d4671bfdcee129115300d0f108d3d8f#diff-4d20e6a15e5a09de1e430f18a7c84eb257eb3d2b98721a35f4853d3fd2dadf37R44

> Currently this is implemented using `Resource` interface and I feel the same mechanism can be extended for handling the new arguments at the application level as well. This can be done by treating the class responsible for processing arguments as a `Resource` which would get the `afterRestore` notification and can then get the new arguments from the Context passed to it.

I still think that taking args as method parameters is cleaner and more streamlined. I would agree that arguments should be stored somewhere and then referred by a method call, if regular CLI arguments are stored somewhere and then referred by the main method. But they are provided as parameters to the main method, so I think we should not diverge in this. I mean, we don't write java programs in such way:

class Main {
  public void main() {
    String args = getArgs();
  }
}


An additional benefit of arguments as parameters -- they could be GCed as soon as a method processing them completes. Having arguments stored would make them eternally consuming memory.

The context to store args does not look as the right place: context's are forming hierarchy, so you'd need to set the args for downstream context when it's notified from the parent context. And arguments make sense only during afterRestore execution.

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

PR: https://git.openjdk.java.net/crac/pull/16