From Lin Zang (zanglin5@jd.com).

Using "jmap -histo" to collect a histogram info on a large ~200g heap took about 160 seconds, which caused our online system to suffer "non-responsive" issues. In addition, if we stop jmap with "kill", jmap exits directly (even though the attached JVM is still working on heap iteration), leaving no info for analysis.

To address the issue above, I proposed following:

1) Extend jmap to be parallel and incremental, which means jmap iterates the heap in parallel and saves intermediate results incrementally during heap scanning (controlled by a threshold to decide when to dump).

2) Make jmap accept arguments that enable/disable parallel and partial heap iteration, also make the number of parallel threads configurable.

3) Make jmap dump results to specified file path given by an argument, rather than output directly to stdout.

A prototype has been made internally with G1 in JDK 11, and our preliminary measurements show that parallel iteration on a ~200GB heap with 4 threads can save ~30-40 seconds, and I am also analyzing an approach to make the time more scaled with parallel threads. Moreover, with the implementation of incremental dumping, we can get useful partial dump info for analysis, even when jmap hangs for a long time, or gets killed for some reason.

Several problems were encountered during development. One problem is that it is not easy to dynamically allocate data structures for thread local operations, such as KlassInfoTable, which is a StackObj that's not allowed to be allocated using "new". Another problem is that some base class definitions must to be modified to support parallel operations, such as ObjectClosure, etc. I am not sure whether these modifications would be acceptable.