Provide ability to pass new system property or update existing property on restore

[Ashutosh Mehra]

*> For example:> java -Dkey1=value1 -Dkey2=value2 -XX:CRaCRestoreFrom=cr>
would pass the system property key1=value1 and key2=value2 to the process
being restored.*

Currently the initiating JVM only serves to write the command line
arguments to shared memory and then calls *exec() *to run the criu engine.

I am wondering if the initiating JVM needs to recognize these properties?
It can probably ignore these properties if the *-XX:CRaCRestoreFrom*
option is present, but then in future if ever there is a need to pass a
system property to the initiating JVM, it wouldn't be possible.
To keep that option open, we would need to differentiate between the
properties that apply to the initiating JVM and the ones that apply to the
JVM being restored.

Any thoughts on this?

Ashutosh Mehra,
Red Hat Runtimes


On Fri, Apr 8, 2022 at 11:47 AM Ashutosh Mehra <asmehra at redhat.com> wrote:

> Similar to the requirement for providing new command line arguments to the
> application on restore,
> it would be useful if the user is able to provide new system properties as
> well.
> For example:
>
> > java -Dkey1=value1 -Dkey2=value2 -XX:CRaCRestoreFrom=cr
>
> would pass the system property key1=value1 and key2=value2 to the process
> being restored.
>
> If key1 is already present as a system property, its current value will be
> replaced with value1.
> If key1 is not present, it gets added as a new system property in the JVM.
> Any other system property already present in the JVM would not be touched.
>
> To implement this we can use the same mechanism as for passing the new
> application arguments,
> i.e. the new system properties would be written to the shared memory by
> the initiating JVM (the instance
> of the JVM that invokes the criu engine for restore).
> I intend to use the same shared memory that is currently used for passing
> the new application arguments.
> The shared memory can be partitioned to store the system properties
> followed by the application arguments.
>
> The restored JVM would read the new system properties from the shared
> memory and add them or update them
> in the Arguments::_system_properties which is the set of system properties
> maintained by the VM.
> In addition, these properties need to be updated in the JDK as well. To
> accomplish that, the java.lang.System
> class would need to be updated to recompute the System::props field.
>
> Note that this only takes care of the JDK and JVM.
> If the application/library has read the property before checkpoint and
> cached it, it would have to register
> the appropriate resource(s) for afterRestore() notification to refresh the
> property value.
>
> If this makes sense, I can work on the changes. If not, feel free to
> suggest any alternatives.
>
> Regards,
> Ashutosh Mehra
>