On Tue, 23 Feb 2021 08:51:15 GMT, Ralf Schmelter <rschmel...@openjdk.org> wrote:
>> 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 > > Hi @linzang > > >> 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~ > > I would guess that is the case. In the compressed case we write about 800 MB > per second, that is as fast as my SSD goes. > > Here are some actual results I've gotten (uncompressed): > > jmap.exe -dump:file=ser.hprof,all 30600 > Dumping heap to ser.hprof ... > Heap dump file created [32009882362 bytes in 59.303 secs] > > jmap.exe -dump:file=par1.hprof,parallel=1,all 30600 > Dumping heap to par1.hprof ... > Heap dump file created [32009885809 bytes in 72.719 secs] > > jmap.exe -dump:file=par2.hprof,parallel=2,all 30600 > Dumping heap to par2.hprof ... > Heap dump file created [32009881876 bytes in 57.546 secs] > > jmap.exe -dump:file=par4.hprof,parallel=4,all 30600 > Dumping heap to par4.hprof ... > Heap dump file created [32009882956 bytes in 44.301 secs] > > jmap.exe -dump:file=par5.hprof,parallel=5,all 30600 > Dumping heap to par5.hprof ... > Heap dump file created [32009882164 bytes in 40.282 secs] > > jmap.exe -dump:file=par6.hprof,parallel=6,all 30600 > Dumping heap to par6.hprof ... > Heap dump file created [32009881156 bytes in 45.988 secs] > > And here for the compressed case: > > jmap.exe -dump:file=par1.hprof.gz,parallel=1,all,gz=1 52372 > Dumping heap to par1.hprof.gz ... > Heap dump file created [8076994216 bytes in 54.057 secs] > > jmap.exe -dump:file=par2.hprof.gz,parallel=2,all,gz=1 52372 > Dumping heap to par2.hprof.gz ... > Heap dump file created [8075859421 bytes in 43.442 secs] > > jmap.exe -dump:file=par4.hprof.gz,parallel=4,all,gz=1 52372 > Dumping heap to par4.hprof.gz ... > Heap dump file created [8075886152 bytes in 28.710 secs] > > jmap.exe -dump:file=par6.hprof.gz,parallel=6,all,gz=1 52372 > Dumping heap to par6.hprof.gz ... > Heap dump file created [8075758374 bytes in 25.730 secs] > > jmap.exe -dump:file=par8.hprof.gz,parallel=8,all,gz=1 52372 > Dumping heap to par8.hprof.gz ... > Heap dump file created [8075652558 bytes in 26.039 secs] > > jmap.exe -dump:file=par16.hprof.gz,parallel=16,all,gz=1 52372 > Dumping heap to par16.hprof.gz ... > Heap dump file created [8075644423 bytes in 31.977 secs] > > jmap.exe -dump:file=par24.hprof.gz,parallel=24,all,gz=1 52372 > Dumping heap to par24.hprof.gz ... > Heap dump file created [8075579546 bytes in 41.094 secs] > > Best regards, > Ralf Dear Ralf @schmelter-sap, Sorry for late response, I got stuck in other work recently. I have uploaded a new update that could help reduce memory consumption and also fix the assertion issue. I have verified it on my machine, May I ask your help to double check it on your side? Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261
