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

[Chris Plummer]

On Fri, 12 Feb 2021 14:24:28 GMT, Lin Zang <lzang at openjdk.org> wrote:

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

Yeah, I'm now thinking just stick with `parallel=<n>`. Sorry about all the noise, but I feel better about this approach now that we've explored all the options. We still need to get `heapdumpext` approved. It might be worth sending out an email to serviceablity-dev just to discuss that one topic, rather than having it in a PR discussion. Among other things, there might be suggestions for a better name to use.

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

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