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

[Lin Zang]

On Sat, 13 Feb 2021 04:11:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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`.
>> It can be specified as some implementation-dependent number of thread executors or alike.
>> Also, I'd prefer to define some upper limit for the parameter `<n>`.
>> Would it be okay to specify it as 9? My assumption is that a real maximum 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.
>
>> 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`.
>> It can be specified as some implementation-dependent number of thread executors or alike.
>> Also, I'd prefer to define some upper limit for the parameter `<n>`.
>> Would it be okay to specify it as 9? My assumption is that a real maximum 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.
> 
> I worry about having to define what the default number or parallel threads is, because it's a (somewhat) complex formula based on the number of processors, plus also has to take into account `-XX:ParallelGCThreads`. Cramming this all into the short help is probably counterproductive. I think basically if you choose something other than 0 or 1, you shouldn't expect to be able to pick a good value for <n> without doing some experimenting.

Just send out a email in serviceability-dev. we can discuss the dumpheapext topic there. 

There is a limitation of parallel thread number so that it never exceed the total_workers defined in hotspot.
so how about we just print how many threads worked on parallel heap insecption and then user get the clue to tune it?

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

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