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

[Dan Heidinga]

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

OpenJ9 looked at how to deal with environment variables [1] and came
up with a reasonable approach that we could copy here.  They register
a file as part of the checkpoint call that will contain the new
environment variable values on restore.  During the restore, they read
the specified file and set the env vars.

We could use a similar approach for System properties.  Rather than
setting the -D options on the command line, register prior to the
checkpoint which file to read, and use that file to pass in the new
properties.

It changes the way that command lines are used between the checkpoint
and restore runs which is slightly less convenient, though not outside
the realm of reasonable approaches given the restore already needs an
extra -XX option.

--Dan

[1] https://github.com/eclipse-openj9/openj9/issues/13545
>
> 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
> >
>