On Thu, 11 Feb 2021 02:39:55 GMT, Lin Zang <[email protected]> wrote:
>> 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. >> >> For reference, the JDK 16 CSR for adding `parallel=<n>` support to `jmap >> -histo` is [8239290](https://bugs.openjdk.java.net/browse/JDK-8239290), and >> the bug to change this to a `noparallel` opiton in JDK 17 is >> [JDK-8261482](https://bugs.openjdk.java.net/browse/JDK-8261482). The CSR is >> [JDK-8261543](https://bugs.openjdk.java.net/browse/JDK-8261543). > > Dear All, > I took the liberity to create a PR (#2519) for the "noparallel" option. Maybe > we could discuss there. And I also found @Hamlin-Li has created a CSR for > that. Thanks a lot! > > BRs, > Lin There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/2379
