Bug ID: JDK-8256451 Add gz option to jmap to write a gzipped heap dump

Type: CSR
Component: core-svc
Sub-Component: tools

Priority: P4
Status: Closed
Resolution: Approved
Fix Versions: 16

Submitted: 2020-11-17
Updated: 2020-11-20
Resolved: 2020-11-20

Summary
-------
Add an option to write a gzip compressed heap dump via the jmap -dump command
Problem
-------
There has been **gz** option for jcmd GC.heap_dump diagnostic command (JDK-8237354), adding the same option to jmap -dump command could help user get compressed heap dump file with jmap.

Solution
--------
Add an "gz=<number>" option to support write compressed heap dump file  via jmap -dump command.

An example would be:

   jmap -dump:gz=4,file=heapdump.gz [pid]

This would trigger a gzip compressed heap dump of the specified VM, using  a compression level of 4.

Specification
-------------
Add an integer option called **gz** to the jmap -dump command. If it is specified, it will enable the gzip compression of the written heap dump. The supplied value is the compression level. The value can range from 1 (fastest) to 9 (slowest, but best compression). The recommended level is 1. 

Diff of Specificaion

         dump-options:
           live         dump only live objects (takes precedence if both "live" and "all" are specified)
           all          dump all objects in the heap (default if one of "live" or "all" is not specified)
           format=b     binary format
           file=<file>  dump heap to <file>
     +     gz=<number>  If specified, the heap dump is written in gzipped format using the given compression level.
     +                  1 (recommended) is the fastest, 9 the strongest compression.

Moving to Approved.
20-11-2020
Hi Joe, Yes, fix version is 16. the explicit compression level is a must to be specified, this is consisit with the jcmd implementation, and there is discussion about it at https://bugs.openjdk.java.net/browse/JDK-8243244. Thanks! -Lin
20-11-2020
Moving to Provisional, not Approved. I assume this change is intended for JDK 16; if not, please adjust the fixVersion. Should an explicit compression level be required?
20-11-2020
Thanks Chris for review! marked as Finalized.
20-11-2020
Yes. I've marked it as reviewed.
19-11-2020
Hi Chris, Do you agree if I set this issue to "Finalize" for a second round of review? Thanks!
19-11-2020
Hi Chris, Thanks to point it out, I will try the GZIPOutputStream way later.
18-11-2020
Yes, the SA jmap and the jmap support built into hotspot do not share any code. However, I would think compression support would be pretty easy to add to the SA version. It's just a matter of leveraging GZIPOutputStream, and of course adding the command line option. I don't think SA support needs to be done as part of this CSR. I just wanted to make sure the discrepancy was called out so other reviewers are aware and find it acceptable.
18-11-2020
Hi Chris, Thanks for your comments. I see your concern and I agree that the jcmd, jmap and jhsdb should be consistent, that is the main reason I try to add "gz" support to jmap, having seen it is already there for jcmd. However, I am not sure whether this CSR could include all these tools? or should I create them seperately? and I am also concern should I create them at present? And I have quickly scanned the code and found that the heap dump implemention of jhsdb jmap is quite different with the jmap/jcmd tools, they don't share the code of heap dump implementation, so may be adding heap dump compression support for SA required much more work. I will take close look to investigate it. So I think maybe it is reasonable to create CSR issues seperately, at the time that the work of adding heap dump compression to SA and jhsdb is started, what do you think?
18-11-2020
We also have SA support for doing heap dumps. See the `jhsdb jmap` command and also the `heapdump` command from within `jhsdb clhsdb`. They both share the same underlying heap dumping support. My concern here is that these two ways of dumping the heap will not support `gz` but the `jmap` command will.
17-11-2020