A number of jcmd commands are implemented in Java. With more of the runtime in Java then it is likely there will be more commands implemented to upcall into Java code. One awkward part to this is commands that print output. At things stands, the existing cases encode the output in UTF-8 to a byte[] that is then printed/sent back to the tool, e.g. `jcmd <pid> VM.system_properties` does an upcall (from the Attach Listener) to a supporting method in VMSupport that returns a byte[] to send as the reply to the tool.
Encoding the output to a byte[] is a bit cumbersome but it works when the output isn't too large. However, it doesn't work well when the output it large as it requires buffering the output in memory. The command `Thread.dump_to_file` sends the output to a file to avoid buffering a potentially multi-MB JSON output in memory.
This issue tracks exploring the feasibility of providing a way for Java code to stream output to the underlying socket/pipe that would avoid unbounded buffering. Ideally, the Java implementation could be called with an OutputStream where it can send the output.
Encoding the output to a byte[] is a bit cumbersome but it works when the output isn't too large. However, it doesn't work well when the output it large as it requires buffering the output in memory. The command `Thread.dump_to_file` sends the output to a file to avoid buffering a potentially multi-MB JSON output in memory.
This issue tracks exploring the feasibility of providing a way for Java code to stream output to the underlying socket/pipe that would avoid unbounded buffering. Ideally, the Java implementation could be called with an OutputStream where it can send the output.
- relates to
-
JDK-8319055 JCMD should not buffer the whole output of commands
- Open