RFR: 8252842: Extend jmap to support parallel heap dump [v10]

Lin Zang lzang at openjdk.java.net
Tue Feb 23 08:40:40 UTC 2021


On Tue, 23 Feb 2021 08:23:49 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi @linzang,
>> 
>> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent. 
>> 
>> Note that the baseline I compared against was not the parallel=1 case, but the old code. The parallel=1 case was always 10 to 20 percent slower than the old code.
>> 
>> Best regards,
>> Ralf
>
> Dear @ralf,
> Really Thanks for benchmarking it!
> It is a little surprise to me that "parallel=1" is 10~20 percent slower than before. I believe this can be avoid with some revise in code. And I also found a potential memory leak in the implementation, WIP in fixing it.
> 
>> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent.
> 
> This data are really interest to me, it seems using gzipped dump is faster than unzipped dump, is the because of disk writing or something else? I would investigate more about it~
> Thanks a lot!
> 
> BRs,
> Lin

Dear @plummercj, 

I have reconsidered the solution of “dumpheapext”, IMHO maybe the name is too specific, for example, if in future there is more arguments for `-histo`, we have to made another command called "inspectheapext".
 
How about create a new command named (e.g.) "jmapext", and make the "dumpheapext" work as the subcommand and be passed to JVM as the 1st argument of "jmapext".  Then in future we don't bothering adding new command, just subcommand (or argument) like "inspectheapext". And hence there may be more easier to extend other commands? 

What do you think? 

BRs,
Lin

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

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


More information about the serviceability-dev mailing list