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

Ashutosh Mehra duke at openjdk.java.net
Fri Apr 1 21:21:07 UTC 2022


On Fri, 1 Apr 2022 17:49:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

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

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?

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

Well, this can be achieved if the new arguments are passed as parameters to `afterRestore()`. We then wouldn't need to store them anywhere.


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. 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. More importantly, it allows the user to basically run a different application on restore! I think this is not what we want, right?

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

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


More information about the crac-dev mailing list