RFR: 8256450: Add gz option to jmap to write a gzipped heap dump [v2]
Lin Zang
lzang at openjdk.java.net
Wed Nov 18 01:25:11 UTC 2020
On Tue, 17 Nov 2020 18:57:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>>
>> revise the uintx format issue for output message
>
> 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.
>
> 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.
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
-------------
PR: https://git.openjdk.java.net/jdk/pull/1251
More information about the serviceability-dev
mailing list