RFR: 8157023: Integrate NMT with JFR
Stefan Johansson
sjohanss at openjdk.org
Thu Dec 1 12:36:12 UTC 2022
On Thu, 1 Dec 2022 11:06:24 GMT, Carter Kozak <duke at openjdk.org> wrote:
>> Please review this enhancement to include NMT information in JFR recordings.
>>
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>>
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>>
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>>
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 861:
>
>> 859:
>> 860: MemBaseline usage;
>> 861: usage.baseline(true);
>
> Perhaps we could collect event timing here, rather than reading the timer for each memory category? That way it’s easier to align events from a single snapshot.
>
> for this sort of event, I’m not sure if it’s preferable to declare only a start time, start==end, or measure start and end time around the ‘baseline(true)’ call.
Sounds like a good idea. The only potential problem would be a thread view trying to visualize all event when they were sent and seeing a lot being exactly equal might be strange. I'll consult the JFR guys to see what's best to make it easy to verify which samples are from the same baseline.
-------------
PR: https://git.openjdk.org/jdk/pull/11449
More information about the hotspot-dev
mailing list