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

[Anton Kozlov]

On 4/11/22 17:44, Dan Heidinga wrote:
>>
>> *> 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
 From my perspective, the VM that is initialized only to be replaced is not a
very straightforward way to restore another VM. I would abandon this for the
java launcher detecting -XX:CRaCRestoreFrom argument. But the launcher would
need to handle -XX:CREngine as well and there would be some code duplication in
the launcher and VM. So I didn't rush to do things right.

I don't think that we'd ever want to handle properties in the initiating VM
that we'd not want to pass to the being restored VM. In the opposite, I like
the same interface for properties passing. Suppose that -XX:CRaCRestoreFrom
fail and -XX:+CRaCIgnoreRestoreIfUnavailable is enabled, the properties
provided for restore would be treated as the usual system properties in the VM
that will run as the fallback in this case.

So I'd vote for using the existing syntax:

> java -Dkey1=value1 -Dkey2=value2 -XX:CRaCRestoreFrom=cr ...

Thanks,
Anton