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

[Thomas Stuefe]

On Tue, 28 Nov 2023 09:39:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > Raising the limit is unrelated to this PR.
> 
> But they are related. Raising the limit is the alternative to this PR, for most users most of the time. I think it was reasonable to ask what kind of size are you seeing, and with what kind of frequency.

Oh, certainly.

> That should help say whether this is a bump the limit situation, or a we-must-fix-this-now situation.

Sure. I am just surprised how contentious the printing of a simple "truncated" message turns out to be. Unfortunately, I am out of time for this PR. Maybe it is just better to leave this unresolved.

> 
> JDK-8319055 says we should rework this in a better way, which I expect we all agree on, and this current PR is a possible solution until that change comes along (which might be undone by JDK-8319055).
> 
> /proc/pid/maps was > 2GB of text? At that point nobody can help you. 8-) 

That was with ZGC, Oracle's own collector, and a 4-5TB heap if I recall correctly. That was a real customer case. The number of mappings relate to the ZUnmapper thread being raced by mutator threads. I think they work on a solution for this, but my point is that this could happen.

>If that maps list ended before showing the high numbers, nobody would be surprised!

I am concerned about truncation that is not immediately obvious; also, when doing support, truncation may happen at other levels (e.g. customer uploads a file to a support web site which truncates the output).

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

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