On Wed, 3 Feb 2021 21:52:00 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> Dear All, >> I have updated the patch and remove the introduction of new "parallel" >> option. So there can be no backward-compatibility issue for jmap -dump >> command. May I ask your help to remove the CSR label if agreed? >> >> BRs, >> Lin > > Hi Lin, When I suggested that it would ok just to just always use the default > number of parallel threads, I wasn't considering that we also have `jmap > -histo`, which also supports parallel threads, but includes an argument to > specify it. For example, `jmap -histo:parallel=<n>`. Now this PR adds > parallel support to `jmap -dump`, but you are suggesting not to have a > parallel option to specify it, and use a default number of threads, which > would be the same as what you would get with `jmap -histo:parallel=0`. So > this is inconsistent. If `-histo` is going to allow you to control the number > of parallel threads, then `-dump` should also. I guess an option would be to > not allow `-histo` to control the number of threads, and have it work just > like you are proposing for `-dump`. Here's another thought. What if we added a new Attach API command called something like `setparallel`. Then when you specify `parallel=<n>` for `jmap -histo` or `jmap -dump`, first JMap would send the `setparallel` command, and then it would send the `dumpheap` or `inspectheap` commands, and they would use the parallel setting from the previous `setparallel` command. I assume of `setparallel` is sent to an older JDK, I think you just get an error message back that can be ignored. Anyway, just throwing this idea out there. I'm not so sure I like it myself, but given we don't have a good solution yet, it may be as good as any of the others. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261
