On Fri, 12 Feb 2021 20:44:55 GMT, Chris Plummer <[email protected]> wrote:
>> 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. 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`. Also, I'd prefer define some limit for the parameter `<n>`. Would it be okay to specify it as 9? My assumption is that a real max 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379
