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

[Thomas Stuefe]

On Wed, 8 Nov 2023 01:05:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If DCmds are regularly asserting, or being truncated, then we should be using a larger buffer shouldn't we? That is what the assert was intended to be used for.

The original bufferedStream did not have a limit. We added a limit with JDK-8220394 because we had cases where VMs were OOM-killed due to an error in printing code. But even beyond errors in printing code, a limit seems reasonable. E.g. when running with ZGC, I had VM.info reports that were larger than 2 GB due to the fragmented memory mapping. Do we want to cache that all?

If you have a limit, all the rest follows:
- it makes sense to signal the truncation to the caller
- it makes sense (though it is optional) to stop printing once the bufferedStream cannot receive the output anymore.

If we don't want a limit, we can either restore bufferedStream to its original state pre-JDK8220394 and live with the danger. Or maybe we can think about caching large output differently. Possibly writing temporary files to /tmp. Ideally, the jcmd communication protocol would allow streaming the output back to jcmd, but that is harder to do, especially not if one wants to remain compatible across JDK versions.

> Having clients of the stream actively check for truncation also seems wrong to me. The basic model of our bufferedStream is that it is presumed large enough for all usecases (hence the assert when not the case) and users don't have to care. Otherwise the normal API approach here would be for write() to return a value indicating truncation so that the caller could consider resizing the buffer.

The truncation check is optional, but reasonable IMHO, see ratio above.

> I don't think clients should be aware of, or worrying about truncation, this way. It seems very intrusive.

Hmm, I'd have thought you agree with this change since when discussing JDK-8220394 you proposed a truncation message:

https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2019-May/034431.html

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

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