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

[Chris Plummer]

On Tue, 23 Feb 2021 08:37:34 GMT, Lin Zang <lzang at openjdk.org> wrote:

> I have reconsidered the solution of “dumpheapext”, IMHO maybe the name is too specific, for example, if in future there is more arguments for `-histo`, we have to made another command called "inspectheapext".
> 
> How about create a new command named (e.g.) "jmapext", and make the "dumpheapext" work as the subcommand and be passed to JVM as the 1st argument of "jmapext". Then in future we don't bothering adding new command, just subcommand (or argument) like "inspectheapext". And hence there may be more easier to extend other commands?

Well, if you want to go that route, maybe you just add a new command called "attachcmd", and it can support any command, new and old. But then that kind of points out the real issue with existing commands in that they are rigid with how many arguments they support, and I think they all suffer from that.

There have been other suggestions on how to deal with this, including having the 1st argument include all the arguments. I think the issue there is that it fails with older JDKs. However, the solution for older JDKs might just be the same as is suggested with "dumpheapext", which is just retry using the old argument passing method if the first one fails (and not including any of the new arguments that the old JDK won't understand anyway). So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.

How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.

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

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