-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
JCMD, using the AttachOperation protocol, sends the whole operation result in one go (first the result -- a 32-bit integer at the beginning of the InputStream, then any additional text output). That precludes using JCMD for any operation that may generate much data.
https://github.com/openjdk/jdk/blob/0aaec97527ddf2b229a9dd6beaa7ff55c635dee5/src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java#L381
Today this causes:
- delays, sometimes long, if a command produces a lot of data. User gets no feedback, jcmd seemingly hangs
- In release builds, we truncate the output without any indication
- In debug builds, we assert (I am trying to change this, but discussions are bogged down on this)
It would be good if JCMD would stream output data as they become available. Currently DCmd in the HotSpot code uses the C++ bufferedStream class to buffer the entire output of a jcmd, and write the output into the socket in one go.
One consideration is backward compatibility. If this change requires changes in both jcmd and hotspot, we still should be able to use new/old jcmds with new/old JVMs (meaning the ability to couple any jcmd from any jdk with any jvm). Possibly by introducing some sort of legacy mode.
It may be that this is not fixable at all, or only at a cost that is too high. If that is the case, at least we then know.
https://github.com/openjdk/jdk/blob/0aaec97527ddf2b229a9dd6beaa7ff55c635dee5/src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java#L381
Today this causes:
- delays, sometimes long, if a command produces a lot of data. User gets no feedback, jcmd seemingly hangs
- In release builds, we truncate the output without any indication
- In debug builds, we assert (I am trying to change this, but discussions are bogged down on this)
It would be good if JCMD would stream output data as they become available. Currently DCmd in the HotSpot code uses the C++ bufferedStream class to buffer the entire output of a jcmd, and write the output into the socket in one go.
One consideration is backward compatibility. If this change requires changes in both jcmd and hotspot, we still should be able to use new/old jcmds with new/old JVMs (meaning the ability to couple any jcmd from any jdk with any jvm). Possibly by introducing some sort of legacy mode.
It may be that this is not fixable at all, or only at a cost that is too high. If that is the case, at least we then know.
- relates to
-
JDK-8319307 DCmds should not assert on truncation and should report truncation
- Open
-
JDK-8336723 Add infrastructure to allow jcmd commands in Java to stream output back to the tool
- Open