RFR: JDK-8286198: [linux] Fix process-memory information

[Thomas Stuefe]

On Tue, 10 May 2022 12:46:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Thomas, when looking at the manpage https://man7.org/linux/man-pages/man3/mallinfo.3.html then the manpage is describing "Total allocated space" as just uordblks , see the output in the example program of the manpage. So maybe it would be better to print mi.uordblks and mi.hblkhd separately so that someone looking at the mallinfo manpage finds exactly the same terminology described there in the JVM output? Maybe in some situations it is useful too to get both values ?

No, it's wrong. Hence this patch (see patch description - the number does not account for large areas allocated by the glibc with mmap). Not sure what the state of that manpage is. But I tested this very thoroughly.

Observe:

### 1a) Old VM allocates 100mio 16 byte blocks:

thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap
C-Heap outstanding allocations: 3128240K

OK.

### 1b) Old VM allocates 16 100mio byte blocks:

thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap
C-Heap outstanding allocations: 5782K

Not OK. It says 5,7M, but we just allocated (payloadsize) ~1.6G.


### 2a) Patched VM allocates 100mio 16 byte blocks:

thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap
C-Heap outstanding allocations: 3171375K, retained: 6440K

Still OK.

### 2b) Patched VM allocates 16 100mio byte blocks:

thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap
C-Heap outstanding allocations: 1611294K, retained: 2553K

Now it looks legit too, compared to (1b). The lower size (1.6G vs 3.1G) stems from the massively lower glibc overhead when allocating large areas instead of tiny blocks.

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

PR: https://git.openjdk.java.net/jdk/pull/8553