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

[Lin Zang]

On Tue, 23 Feb 2021 23:00:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear @plummercj, 
>> 
>> 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? 
>> 
>> What do you think? 
>> 
>> BRs,
>> Lin
>
>> 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.

Hi @plummercj ,

> maybe you just add a new command called "attachcmd", and it can support any command, new and old

I think make it work only for newly added arguments for different command could reduce the implementation complexity. The old command doesn't need to handle the exception. 
And I also found in this way the "attachcmd" will be quite similar with `jcmd` command, it accept different command and pass all argument with one string. Then there maybe another solution -- for "parallel" argument of `jmap -dump`, just change it to the `jcmd` command and passing all arguments as a string.  Then we don't bother with adding the `dumpheapext` command.
 

> 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

Yes, no matter what name it is, the new command must have the ablility to eat the unsupported command exception and then print error info. 



> 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.

The older version for `jmap dump` only passing arguments that is recognized (`file` and `live or all`), and siliently drop the unrecognized arguments without any output. 
I added the logic of print error message in JDK16, with JBS https://bugs.openjdk.java.net/browse/JDK-8251347

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

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