On Wed, 10 Mar 2021 11:33:00 GMT, Lin Zang <lz...@openjdk.org> wrote:
>> 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 Dear Chris and Ralf, May I ask your help to review the related CSR first? both JDK-8260424 and JDK-8261943? https://bugs.openjdk.java.net/browse/JDK-8260424 is for adding `parallel=<N>` option, which IMO also block the merge of #2379. https://bugs.openjdk.java.net/browse/JDK-8261943 is for adding new attach api comment `dumpheapext` Thanks Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261
