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

[Chris Plummer]

On Wed, 10 Feb 2021 08:13:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi Hamlin,
>> 
>>> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.
>> 
>> Sorry that I am a little confuse about it:
>> - Does it mean to disable "parallel=" option to not let user tuning the parallel thread number?  
>> - Or just add a "parallel" or "noparallel" option to change the default behavior? 
>> 
>> Both looks fine with me. But IMHO, regardless the ablility of "tunning", disabling the "parallel=" option maybe cause more backward ability issue. User of JDK16 may get error when using option like "parallel=1".  Although I am not sure how this is important since the parallel options was just introduced to JDK16 and it is not LTS.
>> 
>> BTW, I am not sure whether adding "parallel" requre a new CSR as there already have "parallel=" option. And seems like adding "noparallel" require one, right?  
>>  
>>> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?
>> 
>> I agree, we could start with -histo first, maybe we can discuss in this thread first and then handle it in new PR? 
>> 
>> Thanks, 
>> Lin
>
> Hi Lin,
> Sure, let's discuss -histo in this thread first.
> 
> Hi @sspitsyn @plummercj @linzang 
> My following point is based on my humble opinion that parallel=N is not necessary for user and we should use the largest parallel capability of JVM to do heap histo when user intend to do it in parallel. But if you think this basic opinion is not that correct, please kindly ignore following opinion. :-)
> IMHO, maybe we could make the option simple and automatically speed up heap scan by disabling "parallel=" option and adding "noparallel" at the same time? From user's point of view, "noparallel" will speed up their histo/dump automatically, if they are migrating from jdk15 or prior to jdk15, and also give them a way to fall back to previous serial scan if they would like to do that. Although This way will introduce the compability issue, fortunately JDK16 is not LTS, and maybe we could backport to 16 updates if necessary?
> How do you think about it? Thanks for discussion.
> 
> ( BTW, I might not be able to response timely, as it will be long public holiday the next few days, I'm sorry for the inconvenience. )

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.

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

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