RFR: JDK-8297958: NMT: Display peak values [v4]

[Thomas Stuefe]

On Tue, 6 Dec 2022 15:29:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Oh good catch.
>> 
>> I think this has to do with this ugly hack in MallocMemorySnapshot::make_adjustment():
>> 
>> So, we account chunks with mtChunk. Easy. But we also account for arenas. Arenas consists of chunks. To not report memory twice (once under malloced-with-mtChunk, once as "arena") we decrease the malloc size of mtChunk by the combined arena size of all arenas. What's left should be malloc size of free chunks in the free pool.
>> 
>> But that adjustment messes up the mtChunk malloc counter, since it is implemented as one gigantic free. So the counter is garbage.
>> 
>> I'll think of something.
>
> Thanks for the explanation. I guess the easy fix is just:
> 
> const size_t count = (flag == mtChunk) ? 0 : c->count();

Christ this is complex. :-(

Both detail reporter and summary reporter share this printer code, but via MEMFLAG the print output is subtly changed. MEMFLAG=mtNone is taken as "print in summary report format" and != mtNone is "print in detail report format". This is all fixable but makes the already convoluted report not prettier.

The other option would be to, in MallocMemorySnapshot::make_adjustment(), set the count to zero. But I don't dare this because afterwards the counter would assert if it were to be decreased further.

See this mess? MallocMemorySnapshot is not really usable anymore as counter holder after the adjustment is made, because mtChunk counter got modified and now may assert for negative overflow. I believe MallocMemorySnapshot::make_adjustment() is only valid if you don't modify the counters anymore afterwards.

I decided to leave it as it is. I don't think that anyone cares. As I wrote, I have plans to simplify this.

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

PR: https://git.openjdk.org/jdk/pull/11497