RFR: 8256450: Add gz option to jmap to write a gzipped heap dump [v2]

[Lin Zang]

On Wed, 18 Nov 2020 04:04:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi @plummercj, 
>>      Thanks for your comments! 
>> 
>>> Are the Attach API changes backwards compatible? You've added a new arg, but that arg could be passed to an older JVM that doesn't support it (I think it just gets ignored), or an older JVM would fail to pass the arg to a new JVM that is expecting it.
>> 
>> Correct, the new "jmap -dump:gz=1 [pid]" could work with old JVM and the "gz" option is ignored.  And the old jmap -dump can not accept "gz" option, it fails with error message printed, no matter what jvm version it work with.  I also tested that jcmd GC.heap_dump command with old version of jcmd can not accept the option "-gz=[number]". Moreover, This behavior is similar to "parallel=<num>" option recently added to jmap -histo. So IMHO the risk is not high.
>> 
>> If the "gz" option is not used, jmap -dump could work normally, with different version of jmap command and JVM. (I only tested with jdk8, jdk11 and latest jdk build)
>> 
>>> Also, please see my comments in [JDK-8256451](https://bugs.openjdk.java.net/browse/JDK-8256451) regarding SA heap dumping support, and how it will lack this ability to compress the heap dump.
>> 
>> Yes, I am also considering adding compression support to them, but I am not sure whether there should be new CSR issues created separately to tracking them, and whether I should create those issues at present because I am only planing the work. Let's discuss in the CSR. 
>> Thanks!
>> 
>> BRs,
>> Lin
>
>> And the old jmap -dump can not accept "gz" option, it fails with error message printed, no matter what jvm version it work with.
> 
> I just want to clarify what I was referring to. I was not talking about trying to use gz with the old jmap command (from the command line). I was asking what happens if you use the old jmap command on a newer jvm that does support (and I assume expects) the new "compression level" argument to be passed, but it won't be. We've had this issue before. See [JDK-8219721](https://bugs.openjdk.java.net/browse/JDK-8219721). I haven't had a chance to look at the fix for JDK-8219721 to see if it also solves the issue with this change, or if something similar also needs to be done with this change.

Hi @plummercj ,

Thanks for your explaination. I get your point. 
The issue of JDK-8219721 was fixed by reverting the problematic change. And the root cause of that issue is there is fixed limitation of number of arguments that passing to jvm from attacher, I have figured out a way to avoid touching it when adding new options to jcmd-alike tools, However this PR doesn't even exceed the argument limitation, so it doesn't have chance to cause the similar issue. 

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/1251