RFR: JDK-8319307: DCmds should not assert on truncation and should report truncation [v2]

[Thomas Stuefe]

On Mon, 27 Nov 2023 10:59:57 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi, What jcmds are hitting the limit? Dynamic library list on Linux is mentioned in the bug, so is that a "jcmd PID VM.dynlibs" command which is printing 100MB of output? (/proc/pid/maps is >100MB)

at least the following commands are affected:

VM.dynlibs
VM.info, which prints the process map
System.map, which prints an annotated memory map
VM.native_memory, which in detail mode can get really large

the following command may be affected with high output details:
VM.metaspace

> 
> Is the problem that the buffer has nowhere to drain to at the point the diagnostic command is running? AttachListener executes the whole diagnostic command into a buffer, then calls op->complete(...); which prints the result using e.g. LinuxAttachListener::write_fully().

Yes and yes

> 
> If this no longer works, maybe it's time to use a version of bufferedStream which has knowledge of where output is going. The attachlistener creates the buffer and tells it the destination (the attach listener's socket) so it can actually write it out and clear the buffer when necessary. The AttachListener's call to op->complete would just flush() the buffer.

Yes, already tracked by https://bugs.openjdk.org/browse/JDK-8319055 . It is out of scope for this issue though, and I have no time for it; also, there are backward compatibility issues to be considered. See JBS issue for details.

> 
> If it's only os::print_dll_info(outputStream *st) which is known to fill the buffer, then that one function could limit its own output until there is such a better solution.

`os::print_dll_info` should not have any knowledge of the context it is used in and of the limitations of the stream handed in. That's its caller's business. Lets keep these separated.

The solution would be to go forward with this PR. It is a trivial change, and the current state is unacceptable. Unfortunately, this PR seems to be blocked dead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16474#issuecomment-1827644808