RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel

[Lin Zang]

On Fri, 12 Feb 2021 06:55:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> So maybe we have two choice here:
>>>     * Add a new command for argument extension.   so jcmd and jmap could be consisitent.
>>>     * Remove the "parallel" option in jmap, and leave the control to jcmd.
>> 
>> Yes, I suppose we can still do the `dumpheapext` approach to allow for having 4 args. It's a bit of a hack, but at least it is hidden from the user, and allows `jmap` and `jcmd` to both support `noparallel`
>
> Sigh, I've keep debating this with myself, and keep having second thoughts on what is best. I'm now leaning towards just sticking with `parallel=<n>`, and for any n > 1, at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`. I know this isn't ideal, but I'm guessing for the most part users will just leave this option alone anyway, and will get the default number of threads. But, my current feelings here also hinge on adding `dumpheapext` so `-dump` and `-histo` both support parallel options.

Hi Chris, 

> at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`

I agree. what came in my mind when introducing `parallel=<n>` is that tuning maybe required when user works on multi-processes scenario, for which more parallel threads may affect other processes and disabling parallel may not be affordable when heap is large.

So having seen that there is a solution of 'passing more than 4 agruments' issue, IMO it is fine to keep consistency between jmap and jcmd. Therefore I think we have following choices for `parallel` of jmap and jcmd.

1 - Introduce `noparallel` option, use parallel by default and remove `parallel=<n>`.  It hides the detail info about parallel thread number and hence disable the tuning ability. But it makes user easier to use, just use `noparallel` to control parallalism. And also there is incompatibility issue between JDK16 and the latest JDK.
 
2 - Same as 1, but keep `parallel=<n>` option, and print the threads number for parallel heap inspection at the end. It gives user the ability to tune the parallel thread number, and also reduce the incompatibility between JDK16  and later version since there is no options removed.  But it introduces complexity for user to use `parallel=<n>` and `noparallel` options. (Please note that most users may not care about the parallel thread number in most scenario, just use the default one).

I prefer 2 as for me option 1 is like a subset of option 2, and 2 doesn't introduce backward-compatibility issues 

Thanks 
Lin

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

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