On Wed, 24 Feb 2021 03:46:42 GMT, Lin Zang <lz...@openjdk.org> wrote:
> > But they are far more convenient and easier to understand than jcmd, so > > will probably stay around. But you are right in that they could still all > > be converted to use jcmd internally. > > Maybe we could consider using `jcmd` internally to replace the current > implementation of these tools, and keep their usage as before, then we get > same result from `jcmd` and `jmap` alike tools, get rid of the argument > passing limitation (because jcmd make all argument as a string), and also > reduce the overhead of maintanence (e.g. don't bothering adding new options > for both jmap and jcmd ) It does reduce the maintenance overhead, but you still need to parse the arguments on the client side and package them up the way jcmd likes to see them. > > > Ok, but that fix is on the client side, not the target VM side. > > Yes, it only change the client side to reject illegal arguments, the JVM side > still work as it is - ingore unknown argument silicently. However, the client > side could at least reject unknown option and hence pass correct ones as > expected to JVM. > So if we agree on this change, at least for "parallel=" option, we don't need > to retry when get the exception. :-) Actually you should still see an error when using `parallel` or `gz` when the target VM doesn't understand them. This is because `jcmd` will reject them on the target VM side. Then the question is whether to retry without them, or pass the error to the user and let them adjust their `jmap` command. The problem with the latter is that the arguments in the `jcmd` error message might not look exactly the same as the way they were specified by the user to `jmap`. We'd have take a closer look at the `jcmd` error messages to see if they are appropriate for `jmap` users. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261
