On Wed, 18 Nov 2020 04:04:49 GMT, Chris Plummer <[email protected]> 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
