On Thu, 4 Feb 2021 03:17:28 GMT, Lin Zang <[email protected]> wrote:
> IMO, there can be two ways which may help solve the compatibility issue of
> introducing "parallel" option:
>
> * unblock socket with timeout. In this way, old Jmap could work with new
> JDK, but it maybe complicated because of different implementation for
> different OS.
>
> * Two times communication as you mentioned, it sounds a reasonable
> solution, I will work out a prototype and then discuss with you .
>
A 3rd would be to create a new `dumpheap` command for the Attach API, maybe
`dumpheap_parallel`. If you try using it with an old JVM, it should immediately
return an error:
st.print("Operation %s not recognized!", op->name());
res = JNI_ERR;
If it does, you can fallback to the regular `dumpheap` command. If an old JVM
attaches and uses `dumpheap`, you can choose to make it parallel by default if
you wish. A slightly different variant of this idea is have something like
`dumpheap_extraargs` or `dumpheap_ext`, leaving room to add even more args in
the future (possibly a single argument with a list of args as you suggested
before)
BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd
version will support fine control over parallelism. So for that reason it
wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some
default parallelism, and allow tuning it with the jcmd versions. But since the
`inspectheap` parallel support already went into 16, that might be hard to undo.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2261
