RFR: 8252842: Extend jmap to support parallel heap dump

[Lin Zang]

On Thu, 28 Jan 2021 22:14:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think if you can avoid the 4th argument by just enabling parallel by default sounds like a good idea. Is there any reason not to use parallel heap dump? Also, I'm not familiar with the terms "compression backends" and "active workers". Can you explain them.

For parallel heap dump, I think expose the "parallel" option is useful when user want to control the number of threads that works on parallel dumping. One reason is to control the CPU load to not affect too much on other processes on system. 

The "active workers" is the value that returned by gang->active_workers(). And I think "active workers" is the number of available threads that could be used for parallally working on something. my understanding is that this value could be dynamically changed at runtime, but it is limited by the JVM option "-XX:ParallelGCThreads".

The "compression backend" is introduced by "gz=" option, it is actually a "backend" that write heap dump data to file, and if there is compression level specified, the "backend" will do compression first and then write to file. The whole "backend" works parallelly, before this PR, the backend thread number is dicided by "active workers".

With this PR,  the relation of parallel heap iteration threads (parallel dumper),  the file writing threads (compression backend) and the "active_works" is like following:
          num_of_dumper_threads + num_of_compression_backend = active_workers.

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261