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

[Thomas Stüfe]

On Mon, Aug 10, 2020 at 3:19 PM Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi Thomas,
>
>
>
> > Actually I don't, "kB" is used for sscanf()'ing the proc file. All
> printouts are in "K".
>
> Sorry, you’re right.
>
>
>
> > kbyte are not consistently used - we have "k", "K", "KB".
>
> What a mess!
>
>
>
> > I opted for "K" since NMT and the heap summary use that.
>
> So we report sizes in Kelvin ��
>

XD

you are right. Well we can fix this in a follow up later.


> I don’t like "K", but if it’s already used, you can just ignore my
> complaint.
>
>
>
> Best regards,
>
> Martin
>
>
>

Thanks, Thomas


>
>
> *From:* Thomas Stüfe <thomas.stuefe at gmail.com>
> *Sent:* Montag, 10. August 2020 14:33
> *To:* Doerr, Martin <martin.doerr at sap.com>
> *Cc:* David Holmes <david.holmes at oracle.com>; Hotspot dev runtime <
> hotspot-runtime-dev at openjdk.java.net>
> *Subject:* Re: RFR(xs): 8251255: [linux] Add process-memory information
> to hs-err and VM.info
>
>
>
> Hi Martin,
>
>
>
> re-read your mail:
>
>
>
> On Mon, Aug 10, 2020 at 2:24 PM Doerr, Martin <martin.doerr at sap.com>
> wrote:
>
> Hi Thomas,
>
> looks like a really helpful contribution.
>
> Minor nit: You print most values in "kB", but some other ones in "K". I
> think "kB" should be used consistently.
>
>
>
> Actually I don't, "kB" is used for sscanf()'ing the proc file. All
> printouts are in "K". kbyte are not consistently used - we have "k", "K",
> "KB". I opted for "K" since NMT and the heap summary use that.
>
>
>
> So I think if its okay with you I leave that part as it is.
>
>
>
> I don't think kernel < 2.6.34 is still supported. I don't care if you
> remove the check or not.
>
> Otherwise thumbs up from my side. I don't need to see another webrev.
>
> Best regards,
> Martin
>
>
>
> Thanks, Thomas
>
>
>
>
>
> > -----Original Message-----
> > From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> > On Behalf Of Thomas Stüfe
> > Sent: Montag, 10. August 2020 13:52
> > To: David Holmes <david.holmes at oracle.com>
> > Cc: Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
> > Subject: Re: RFR(xs): 8251255: [linux] Add process-memory information to
> > hs-err and VM.info
> >
> > Thanks for the review, David!
> >
> > On Mon, Aug 10, 2020 at 1:42 PM David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> > > Hi Thomas,
> > >
> > > This seems fine to me.
> > >
> > > Thanks,
> > > David
> > >
> > > On 10/08/2020 9:32 pm, Thomas Stüfe wrote:
> > > > Hi,
> > > >
> > > > new version:
> > > >
> > > >
> > > http://cr.openjdk.java.net/~stuefe/webrevs/8251255-add-rss-to-hs-
> > err/webrev.01/webrev/
> > > >
> > > > - changed the type of the receiver variables to ssize_t
> > > > - enclosed mallinfo call with __GLIBC__
> > > >
> > > > Thanks, Thomas
> > > >
> > > > On Thu, Aug 6, 2020 at 4:01 PM Thomas Stüfe
> > <thomas.stuefe at gmail.com
> > > > <mailto:thomas.stuefe at gmail.com>> 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 :)
> > > >
> > > >     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.
> > > >
> > > >     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 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
> > > >
> > >
>
>