RFR: 8252842: Extend jmap to support parallel heap dump [v10]

[Chris Plummer]

On Wed, 24 Feb 2021 00:22:16 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  I just realized that my understand is a little different with the "retrying" - if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough. This is consistent with JDK16.
> But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.

It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK. When I tried it, it silently worked, but without compressing the output file. Since jmap doesn't know what JDK it is communicating with, I can only assume it tried passing `gz=`, and when that failed and retried without it. Or maybe the old JDK is just silently consuming the unrecognized `gz=` argument. I'd like to understand the implementation behind this behavior.

> So maybe we can also revert the argument parsing logic introduced in JDK16? 
I'm not sure what you are referring to here.

> But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.
If the target VM cannot accept the argument, our choices are either silently ignore that and retry without the argument (which might mean using a different attach command), or produce an error message. I can see an argument for either approach. I tend to favor the error message (and therefore no retry), but if you have scripts that might target various VM versions, you might want the bad argument to be silently ignored. This is especially true for `parallel` since it doesn't impact the output, but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.

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

PR: https://git.openjdk.java.net/jdk/pull/2261