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

[Serguei Spitsyn]

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

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

I also think, it is better to stick with `parallel=<n>`.
Then it has to be explained what is the default number of parallel threads for the option `-parallel=0`.
Also, I'd prefer define some limit for the parameter `<n>`.
Would it be okay to specify it as 9? My assumption is that a real max would be the default number of parallel threads.
If it is too high then it is possible to pick any number between 1 and 9.

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

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