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

[Chris Plummer]

On Thu, 18 Mar 2021 14:40:57 GMT, Lin Zang <lzang at openjdk.org> wrote:

> * Is it acceptable that `jmap -dump` and `jmap -histo` have different behavior about the option of `parallel`, that is, `heapdump` does not use it and `heaphisto` does.

And just to further clarify, the parallel support for `jmap -histo` is already in JDK 16, which is one reason we were swayed towards including it with `jmap -dump`. If we didn't we were thinking in order to be consistent we would need to pull the parallel support for `jmap -histo`, which would be somewhat problematic since it will already have shipped in 16. However, given that these are really two different commands, and we have some good arguments for not including parallel support for `jmap -dump`, I can see leaving it out.

> * If we decide to not introduce the `parallel` option, we don't need to introduce the `heapdumpext` attach api command, so the 2 CSRs related to this PR could be closed. But this may leave the argument count problem to future, when more argumebts is introduced, is this acceptable?

Yes, and in fact I would argue that we should not be doing the `heapdumpext` solution now if we no longer have a need for it.

> * if we decide to introduce `parallel=<N>` option, do we need to add explaination in the document? or docs like tuning guide?

Which document were you thinking? Is the turning guide a hotspot tuning guide? If so, I don't think that's the right place for it. The focus should be in any jmap documentation.

And to add a 4th bullet item to your list, we also have the `GC.heap_dump` jcmd. I think there as a CR and CSR to add parallel support to it (but honestly I've lost track). If we choose not to include parallel support for `jmap -dump`, I think we should exclude it from `GC.heap_dump` also.

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

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