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

[Thomas Stuefe]

On Tue, 19 Aug 2025 18:59:18 GMT, Erik Gahlin <egahlin 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>
> ```

Hmm, yes, that would be one alternative.

> 
> 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.

I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation.

Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way.

In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption—especially rss+swap. You need swap to be able to explain rss.

I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the most important platform.

On Windows, for example, we can ask for the size of the commit charge. That is a nice complementary information. On Linux, we also have a commit charge (as in, how much of the process memory was committed by the OS, underlaid with swap according to the kernel overcommit rules). That would be useful to know, since it can explain native OOMs when the OS runs out of swap. But I don't see a way to obtain that information on Linux. Since I only have the number on Windows, I left it out. And I realize this is a bit arbitrary, since I included values I only get for Linux.

Shaping events the right way is hard, and I am thankful for any direction from your side.

> 
> > 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.

Hm, sure.

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

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