On Sat, 13 Feb 2021 04:11:55 GMT, Chris Plummer <[email protected]> wrote:
>> 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`. >> It can be specified as some implementation-dependent number of thread >> executors or alike. >> Also, I'd prefer to define some upper limit for the parameter `<n>`. >> Would it be okay to specify it as 9? My assumption is that a real maximum >> 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. > >> 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`. >> It can be specified as some implementation-dependent number of thread >> executors or alike. >> Also, I'd prefer to define some upper limit for the parameter `<n>`. >> Would it be okay to specify it as 9? My assumption is that a real maximum >> 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. > > I worry about having to define what the default number or parallel threads > is, because it's a (somewhat) complex formula based on the number of > processors, plus also has to take into account `-XX:ParallelGCThreads`. > Cramming this all into the short help is probably counterproductive. I think > basically if you choose something other than 0 or 1, you shouldn't expect to > be able to pick a good value for <n> without doing some experimenting. Just send out a email in serviceability-dev. we can discuss the dumpheapext topic there. There is a limitation of parallel thread number so that it never exceed the total_workers defined in hotspot. so how about we just print how many threads worked on parallel heap insecption and then user get the clue to tune it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2379
