On Tue, 23 Feb 2021 08:23:49 GMT, Lin Zang <lz...@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
