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

[Lin Zang]

On Wed, 10 Mar 2021 11:33:00 GMT, Lin Zang <lzang at 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