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

Anton Kozlov akozlov at openjdk.java.net
Sat Mar 5 07:45:29 UTC 2022


On Fri, 4 Mar 2022 15:36:14 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Is there a design doc that describes the intended behaviour and limitations of this approach? I've read the description in the PR but there's more to call out about what options can reasonably change. ie: jvm options are unlikely to be successfully changed while passing new application args may be OK (if the app is written to handle that)

At the momement only CLI arguments are passed. I think it won't be hard to extended this for system properties (-D...). Environment variables would be more tricky. JVM options are of course under a big question. I'm looking at CLI arguments as they cannot change,  in contrast with properties or the environment (I'm thinking e.g. an another java thread that may change them). Some JVM properties can be changed by existing mechanisms (`MANAGEABLE`). But unlikely all JVM options can be made manageable -- although in theory possible, this won't be practical (resize heaps because Xmx, regenerate code because codegen options,..). But some of options are not manageable but can be allowed, like PrintCompilation. Either they need be turned to manageable, or another term should be invented, or we may use ad-hoc checks for each and warn the user the option may not be changed. Let's try to find a useful and practical set? It looks to be CLI arguments, system properties, environment, and a subset 
 of JVM options.

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

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


More information about the crac-dev mailing list