On Thu, 28 Jan 2021 21:55:41 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> Hi Lin, >> It is also in my memory that you actually did not have 4 arguments. >> The real incompatibility issue was that the order of arguments was swapped. >> It is why it was relatively easy to fall back and just update the constants >> with 3 instead of 4 and swap the order of arguments back. >> Thanks, >> Serguei > >> It is also in my memory that you actually did not have 4 arguments. >> The real incompatibility issue was that the order of arguments was swapped. > > Ah, now the fix makes a lot more sense. I was always wondering how changing > the order allowed reducing the max args to 3, but apparently the two changes > are not related. Also, it seems them that > [JDK-8219721](https://bugs.openjdk.java.net/browse/JDK-8219721) does not have > a correct analysis of the issue. It says: > >> JDK-8215622 increased number of arguments of Attach API [1]. >> Thus AttachListener will be waiting the command from client infinitely. > > Perhaps it should be updated to avoid future confusion. I think if you can avoid the 4th argument by just enabling parallel by default sounds like a good idea. Is there any reason not to use parallel heap dump? Also, I'm not familiar with the terms "compression backends" and "active workers". Can you explain them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261
