Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8319055

JCMD should not buffer the whole output of commands

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • tbd
    • None
    • hotspot
    • svc

      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.

            Unassigned Unassigned
            stuefe Thomas Stuefe
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: