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

[Thomas Stuefe]

On Tue, 28 Nov 2023 07:47:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Caller needs to take care of it.
>> 
>> In my mind, the caller knows what stream class it uses, so it knows if the stream is one that can truncate. So its his responsibility to handle stream::is_truncated. In this case, the caller that uses a truncatable stream is the dcmd framework, and it handles this.
>> 
>> The printing routines themselves could be completely oblivious to it, I only query truncated in a handful of places to save work - if we know the output stream truncated, there is no reason to continue work printing (and potentially, holding a lock while doing it).
>
> Okay, so it isn't clear to me that all of these situations are such that the caller is always a DCmd and that it always reports the truncation due to the attach code changes.

But we also truncate today, we just don't tell anyone! All this code does is:
- in some cases, where we truncated silently before, we now - equally silently - stop printing since its pointless to print to a full buffer
- if we truncated while feeding a Dcmd, tell the end user.

Yes, there are more instances where we use bufferedStream, and there may be more instances where this buffer does not flush but silently truncates. Even after this PR. But this PR never claimed to fix those. What it does, beyond the immediate dcmd fix, is to offer a sensible way to sense truncation, and to act on it if desired.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16474#discussion_r1407463136