How to add platform-specific metrics?

Thomas Stüfe thomas.stuefe at gmail.com
Tue Aug 5 14:27:58 UTC 2025


Follow-up question:

Is there some process to deprecate/reshape Events?

For example, let's say I want to introduce Process vsize and swap as
metrics. The most reasonable way would be to group these metrics with RSS
and RSSPeak into one event. There is no need for separate Events for these
values (it is unlikely that someone ever needs different collection
intervals, for example), and these are retrieved in a single operation
anyway, so retrieving them all in one go is faster than doing it separately
for every metric, and it also prevents polluting the Event space with tons
of events.

But there are problems: the event name for RSS is "ResidentSetSize". That
is probably not a good name for a combined event, which I would name
something like "ProcessMemory", with metrics like "rssUsage",
"rssPeakUsage", "vsize", "swap", or similar. But this would change the
existing ResidentSetSize event. This Event is the base for the RSS chart
printed in JMC, so I guess JMC would have to be adapted - but if it is, it
won't be able to read old jfr files anymore? So I wonder, how is backward
compatibility handled in JFR? Is there a process? Or are we stuck with old
decisions forever?

Thanks!

Kind Regards, Thomas


On Tue, Aug 5, 2025 at 10:14 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi,
>
> short JFR question:
>
> Is there an accepted way to add OS/Arch/Runtime-specific metrics, exclude
> them where they don't make sense (both in JFR and JMC), and name them
> clearly as what they are? One example of many: "glibc memory retention".
>
> From what I see, everything I add would have to be forced through some
> platform-agnostic lens? As in, find some umbrella name for it over all
> configurations (OSes/libc variants/Architectures), even if the metric makes
> no sense on other configurations.
>
> Thanks,
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250805/d9fae589/attachment.htm>


More information about the hotspot-jfr-dev mailing list