On Tue, 23 Feb 2021 23:00:30 GMT, Chris Plummer <cjplum...@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
