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

[Chris Plummer]

On Thu, 11 Feb 2021 02:39:55 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> I'm in favor of just having a `noparallel` option (default to using parallel) instead of using `parallel=<n>`. This would be for both the histo and heap dump features, and for both the `jmap` and `jcmd` support of these features.
>> 
>> As for the current `parallel=<n>` support for jmap histo already in JDK 16, hopefully there would be no objections to removing that in JDK 17 in favor of the `noparallel` approach, but I think the CSR for that change should get some good scrutiny. I think it would good to get approval from @AlanBateman and/or @dholmes-ora since they are both in the CSR group and have good serviceability knowledge.
>> 
>> For reference, the JDK 16 CSR for adding `parallel=<n>` support to `jmap -histo` is [8239290](https://bugs.openjdk.java.net/browse/JDK-8239290), and the bug to change this to a `noparallel` opiton in JDK 17 is [JDK-8261482](https://bugs.openjdk.java.net/browse/JDK-8261482). The CSR is [JDK-8261543](https://bugs.openjdk.java.net/browse/JDK-8261543).
>
> Dear All, 
> I took the liberity to create a PR (#2519) for the "noparallel" option. Maybe we could discuss there.  And I also found @Hamlin-Li has created a CSR for that. Thanks a lot!
> 
> BRs,
> Lin

There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts?

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

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