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

[Robert Toyonaga]

On Wed, 20 Aug 2025 05:22:23 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.
>
>> > 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 exa...

@tstuefe 
I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not touching `jdk.ResidentSetSize`) makes sense. 
- This allows JMC to continue as normal
- And also keeps the relevant metrics together so they can be easily interpreted in relation to each other.
- @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go this route, maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation at some point in the future to allow JMC time to eventually switch over to using the new event for its charts? 


> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? 

 I think this new swap data is process-specific so is not already covered by `jdk.SwapSpace`, which shows the max amount available and how much is currently free to the OS.  
I think it could be reasonable to leave the process' swap data in `ProcessSize` rather than the `jdk.SwapSpace` which contains data for the whole OS. The connecting thread is that this info is a "process" metric being grouped with other memory metrics for this specific process. 

Another option, in order to avoid duplication, could be to leave the RSS metrics in the `jdk.ResidentSetSize` event, not put them in the `ProcessSize` event, and correlate them by giving them the same timestamp as (Erik mentions above). 
Something similar was  also done with the `NativeMemoryUsagePeak` and `NativeMemoryUsageTotalPeak` events (which are GraalVM specific) to avoid having to modify `NativeMemoryUsage` and `NativeMemoryUsageTotal`. Admittedly, this is not as clean or convenient. 

Either way, I agree that putting all the metrics in `ProcessSize` in their own individual events is not the best way.

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

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