RFR(xs): 8251255: [linux] Add process-memory information to hs-err and VM.info

[David Holmes]

Hi Thomas,

On 7/08/2020 12:01 am, Thomas Stüfe wrote:
> Hi,
> 
> may I please have reviews for this addition:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8251255
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8251255-add-rss-to-hs-err/webrev.00/webrev/
> 
> When analysing a customer memory leak recently I found for all
> the information we have in the error files we miss some really fundamental
> statistics like process virtual size and rss. Either that or I am blind :)

This doesn't seem unreasonable, though I don't like to see continued 
divergence between what gets reported on Linux versus other platforms.

Also is this something that is reasonable to always do or should it be 
added to the set of things under ExtensiveErrorReports?

> In case I am not blind this patch adds those statistics. I decided against
> dumping proc files wholesale to the hs-err file, I just print out what I
> really find useful.

+   FILE* f = ::fopen("/proc/self/status", "r");
+   char buf[256];
+   while (::fgets(buf, sizeof(buf), f) != NULL && num_found < num_values) {

But without counting the characters (and knowing what is fixed-width and 
what is variable) doesn't this risk getting a partial entry at the end 
of the buffer such that you won't see it when trying to parse?

> Note that among other things I print out the total size of outstanding heap
> allocations. Note that still the best way to do this is via mallinfo, and
> that means the returned value is int and may wrap, see coding and comment.
> Even with this caveat though this info is still very useful.

I am less keen on this bit. Now I understand your query in another RFR 
about how to flag such glibc'isms so they don't impact building against 
different libs like musl. :)

Is mallinfo safe to call from a signal handling context? I mean that in 
a practical sense (ie it doesn't try to acquire internal malloc locks) 
rather than being designated as async-signal-safe.

Thanks,
David
-----

> I did a number of manual tests, the numbers seem legit.
> 
> Looks like this:
> 
> Process Memory:
> Virtual Size: 7494372K (peak: 7559908K)
> Resident Set Size: 271264K (peak: 571348K) (anon: 226460K, file: 44804K,
> shmem: 0K)
> Swapped out: 0K
> C-Heap outstanding allocations: 37845K
> 
> 
> Here I simulate a C-Heap memory leak:
> 
> Process Memory:
> Virtual Size: 9062260K (peak: 9118772K)
> Resident Set Size: 1941776K (peak: 1941776K) (anon: 1896872K, file: 44904K,
> shmem: 0K)
> Swapped out: 0K
> C-Heap outstanding allocations: 1291984K
> 
> 
> Same leak, with the mallinfo value wrapped around:
> 
> Process Memory:
> Virtual Size: 12343352K (peak: 12445556K)
> Resident Set Size: 5232084K (peak: 5281512K) (anon: 5187052K, file: 45032K,
> shmem: 0K)
> Swapped out: 0K
> C-Heap outstanding allocations: 15454K (may have wrapped)
> 
> Thanks, Thomas
>