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

[Anton Kozlov]

On Fri, 1 Apr 2022 21:17:52 GMT, Ashutosh Mehra <duke at openjdk.java.net> wrote:

> So I am assuming that if an application needs to accept new arguments to restore, it would be to make some internal adjustments. And I would expect the application to model any adjustments post restore using Resource interface. So essentially, what I am trying to say is if the application is using new arguments, there would be _some_ `Resource` that would take _some_ action in `afterRestore()` notification based on the new args. Do you see any other way the new arguments could be used?

The problem is that you cannot guarantee a single resource will handle the arguments. Providing arguments for every resource will encourage Resources using them, while only a single Resource should actually do that.

Resources are required to register different unrelated modules of the program, from third-party libraries to JDK. Each Resource at the smallest is a file handler, or network connection, or e.g. a native part of Selector on Linux (EPoll). Resources are more suited for non-precise checkpoint which comes at a random moment in time -- when you cannot provide a single routine to de/re-initialize, or it's hard.

E.g. microservice main endpoint and service logging endpoint -- each endpoint should be likely a resource, as they are likely handled with different parts of the program and fitting them in the single resource will be rather hard (was the logging endpoing is configured, was it initialized,...).

> Well, this can be achieved if the new arguments are passed as parameters to afterRestore()

This will encourage resources using new arguments even more. I've thought about adding another kind of resources (related/completely unrelated to the existing ones), but I see only a little value in them, but they are not better than the class.

> I think the main concern from my point of view with the current approach was the new main class that the user needs to create to access the new arguments. 

I don't completely understand the concern. How a new Resource is different from this point of view? It's a change anyway. But with the new class it's possible to make it easier and to provide a common class in JDK for all users (I'm not sure the particular class is a great idea):


public class jdk.crac.util.StoreArgs {
  String[] newArgs;
  public static main(String[] args) {
    newArgs = args;
  }
  public static String[] getNewArgs() {
    return newArgs;
  }
}


That is, a class that called if you really need to store new arguments somewhere. 

Or another class that prints image state (Thread dump?) and exits.

> And I realized another implication of this approach which somehow I missed out earlier (not sure if this has already been thought about) - it essentially gives unlimited control to the user to do anything on restore. It allows the application developer to update the objects, instead of doing through the Resource interface. So now they have to choose which approach to use for post-restore adjustments.

I hope I've addressed this above. I expect that Resources won't need arguments as they do not need them now, and a separate mean for handling arguments would not necessary need to be a Resource.

> More importantly, it allows the user to basically run a different application on restore! I think this is not what we want, right?

Why not? An image could be suited for different purposes. A regular java program may have different entry points (classes with the main method) and only one of them employed in a single run. With the restore, the old program does not go away, just another class's main method is called before returning from checkpointRestore().

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

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