RFR: JDK-8317683: Add JIT memory statistics [v3]

[Francesco Nigro]

On Thu, 12 Oct 2023 05:46:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> My testing passed. You need second review.
>
>> My testing passed. You need second review.
> 
> Thank you, Vladimir!

@tstuefe 

> Is your concern about memory that has been freed and is retained by the libc? In other words, a temporary spike that carries over into a permanent RSS increase? In that case, a clear answer is difficult since there is no clear 1:1 relationship between a single malloc and that block of memory.

Yep, exactly and the fact that anon malloc arenas in pmap/maps are un-labelled it won't help to correlate the fact that they are first allocated (and got '`mprotect`) from threads we care about their activity (and we know upfront their identities eg Compiler threads).
My point (sorry if I didn't make it clear) is that we "could" propose to the glibc maintainers something similar to what https://patchwork.sourceware.org/project/glibc/patch/20230927203815.1843924-1-irogers@google.com/ has done, which allow to report to thread-local malloc arenas anon mappings (hence is VERY specific of glibc malloc, in the first iteration) the tid (as a label in pmap) which has `mprotect`-them the first time (ie hence who is responsible for the RSS increase, by consequence). 

As you rightly said, this information won't be enough alone to spot the guilty method compilation (and level), but in my mind I can picture this type of investigation workflow:
- there is a report of increased RSS
- we check first the `pmap -X` output to find if C1/C2 compiler threads anon mappings and diff them from the good version
- if we have an increase there we go down into the rabbit hole with the JIT statistics you provided

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

PR Comment: https://git.openjdk.org/jdk/pull/16076#issuecomment-1759104914