Dear All,
I want to get your suggestion about adding a new internal command
to solve the argument passing problem of jmap alike tools.
We recently encounter a problem when adding the 4th option
(“parallel”) to jmap -dump, it failed because there is limitation of max number
of arguments passed to JVM in attach API. As limited by arguments length at
https://github.com/openjdk/jdk/blob/95d73129ce5074d3510710e7e238761a9af9ef3a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java#L144
and arg_count_max at
https://github.com/openjdk/jdk/blob/95d73129ce5074d3510710e7e238761a9af9ef3a/src/hotspot/share/services/attachListener.hpp#L138.
And simply enlarge this limitation is not acceptable because it
cause old version of jmap command hang when working with new JVM, which has
been encountered and disscussed before at
https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html,
However the problem was not fix at that time because the limitation is
modified unnecessarily and simply revert the change is ok.
As mentioned, now we are facing the problem when developing the
parallel heap dump, which introduced the 4th argument “parallel=<N>” into jmap
-dump command. We (Chris, Serguei, Hamlin and I) recently discussed it and
Chris has suggested a solution to fix this kind of issue by introducing a new
internal command “dumpheapext”. When “jmap -dump” command work with “parallel”
option, it issues “dumpheapext” command instead of “dumpheap” command, and this
dumpheapext has same argument passing protocal with JVM – e.g. “all arguments
passed is combined into one string, passing the whole string to jvm, and the
jvm parse it to get correct ones”.
With this change, old jvm will print error like “Operation
dumpheapext not recognized!” when work with new “jmap -dump:parallel=<n>”
command. IMO this is not perfact as error message like “unsupported argument
parallel=<n>”, but the command behaves correctly and in this way there is no
severe compatibility issue introduced.
Here are some of the discussions before, FYI:
1. https://github.com/openjdk/jdk/pull/2261 - Parallel heap dump PR, with
latest commit of dumpheapext command prototype. Also some history of the story
included in this PR.
2. https://github.com/openjdk/jdk/pull/2379 - improve jcmd
GC.class_histogram to support parallel, we also discussed serveral solution
here.
3.
https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html
The problem encountered proviously, and also discussions related.
BRs,
Lin
