RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR

[Erik Gahlin]

On Tue, 19 Aug 2025 06:58:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> You mean adding the vsize, swap etc fields to ResidentSetSize?
> 
> I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)

I was thinking something like this:


<Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
  <Field type="ulong" contentType="bytes" name="size" .../>
  <Field type="ulong" contentType="bytes" name="peak" ..  />
  <Field type="ulong" contentType="bytes" name="anonymous"   />
  <Field type="ulong" contentType="bytes" name="file" />
  <Field type="ulong" contentType="bytes" name="sharedMemory"  />
</Event>


When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. 

>  Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. 

Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.

These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.

> It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance).

We should not sacrifice the design unless the overhead is significant.

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3201882624