On Fri, 12 Feb 2021 14:24:28 GMT, Lin Zang <[email protected]> wrote:
>> Sigh, I've keep debating this with myself, and keep having second thoughts >> on what is best. I'm now leaning towards just sticking with `parallel=<n>`, >> and for any n > 1, 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 know >> this isn't ideal, but I'm guessing for the most part users will just leave >> this option alone anyway, and will get the default number of threads. But, >> my current feelings here also hinge on adding `dumpheapext` so `-dump` and >> `-histo` both support parallel options. > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379
