[crac] RFR: Allow users to pass new properties on restore

[Anton Kozlov]

On Tue, 3 May 2022 16:32:03 GMT, Ashutosh Mehra <duke at openjdk.java.net> wrote:

> My main intention of this patch is to allow users to specify different properties through command line when restoring the process.

Completely agree. I think this is the most useful part of the properties update feature. That's unfortunate that JDK properties are such problematic, that's why I'd like to avoid doing something completely new with an unclear path to validate, and instead do something familiar for users.

> I am assuming in this scenario the user would want the new properties to have same effect as when starting a new JVM process. In this respect this mechanism is different from calling `System.setProperty()`

> We would want the VM view of the system properties to also be updated. Another reason for updating `_system_properties` is JVMTI api `GetSystemProperties()` which relies on `_system_properties`. After restore `GetSystemProperties()` should provide the system properties that take into account new properties specified on commnad line.

Could you elaborate a bit more about the setting properties as in a new JVM process? E.g. why this cannot be avoided, or when this can be useful compared to other approaches?

I like the JVMTI example because it is another model we can follow. I think we need to choose one model (JVMTI and j.l.S.properties are identified for now), follow it, and try to understand how much it satisfies users' needs. Or at least ours :)

Updating _system_properties scares me. They are not changed with System.getProperties and a JVMTI agent can only change them during OnLoad phase [1]. Is there a way to change them once the java code started to execute?

[1] https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#SetSystemProperty

> Now, for some jdk internal properties, we may be able to consider the new values, but I believe it would not be possible for every jdk internal property. This is the reason why I wanted to separate out the properties that can be modified from those which cannot be.

I would like to distinguish setting a value for a property and the way or the point when the value is processed by some unrelated entity to the way the property is set. Handling is a very implementation detail.

System.setProperty can change any system property. JVMTI SetSystemProperty cannot change only ones with SystemProperty::_writeable == false, and there are not so many of them. For example, "java.vm.specification.name" cannot be set in _system_properties, but can be set by System.setProperty.

Depending on the property, it may be processed at any time. A common pattern is to cache the value in the initialization of a class that will use that later. So updating a JDK property in System.properties may make sense early. And a set of VM properties follow a pattern to get the value early in JDK bootstrap before it can be changed by System.setProperty. For example, "sun.nio.MaxDirectMemorySize". So even if the property is updated in _system_properties, the value is likely to be cached in JDK. But the visible update in _system_properties may trick JVMTI code about the actual value used by the platform (JDK in this case).

> I don't have strong preference about either of these mechanisms, considering these are temporary changes and expected to be removed once we find a better mechanism to initiate restore operation. So if you feel adding Explicit marker is better I can introduce that change.

I'm not sure. Having that there is another pass over all of the arguments anyway, is it possible to provide all explicit native arguments to the function doing the restore (os::Linux::restore for now)? Then we won't need to introduce a lot of aux code in the VM and it will be simpler to move out VM eventually.

PS. Thanks for the recent changes, I haven't read them in detail, but the structure looks better IMO.

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

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