RFR: 8157023: Integrate NMT with JFR

[Stefan Johansson]

On Thu, 1 Dec 2022 11:18:07 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 832:
> 
>> 830: 
>> 831:   MemBaseline usage;
>> 832:   usage.baseline(true);
> 
> In an ideal world we could report totals and category information from the same snapshot, however the periodic event infrastructure doesn’t seem to provide a great way to do that. I don’t think that’s a big deal, but may be worth documenting to avoid confusion as totals may be reported lower than the sum of the parts due to temporal drift.
> 
> An option I had considered is to define some form of larger “NMTSummary” event with reserved+committed fields for each category as well as the totals. The reporting structure would align with the existing NMT summary tooling, but the event would need to be kept up to date with new NMT types, which may not be worthwhile (unless we can create dynamic events using the c apis, which would make things easier). Unclear how this data would be visualized out of the box. I don’t have as much context as I’d like around event design considerations, there may be other reasons I’m not aware of that this suggestion is a bad idea.

I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 

I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.

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

PR: https://git.openjdk.org/jdk/pull/11449