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

[Thomas Stuefe]

On Wed, 20 Aug 2025 19:57:56 GMT, Robert Toyonaga <duke 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 m...
>
> @tstuefe 
> I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not changing `jdk.ResidentSetSize`) makes sense. This allows JMC to continue as normal,  and it also keeps the relevant metrics together so they can be easily interpreted in relation to each other.
>>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.
>     
> @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go the above route (leaving all the metrics in `ProcessSize`), maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation 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 probably 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.

Thank you, @roberttoyonaga ! Let's see what @egahlin writes.

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

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