On Wed, 10 Feb 2021 08:13:33 GMT, Hamlin Li <[email protected]> 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
