RFR: 8157023: Integrate NMT with JFR

[Stefan Johansson]

On Thu, 1 Dec 2022 17:45:25 GMT, Thomas Stuefe <stuefe 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 25:
> 
>> 23:  */
>> 24: #include "precompiled.hpp"
>> 25: #include "jfr/jfrEvents.hpp"
> 
> I think this is an intermixing of layers. I think it would be cleaner if if JFR accessed the current values from outside, instead of JFR knowledge leaking into NMT.

Not sure I agree, I see the `MemReporter` as the reporting layer and it now knows about JFR to be able to report through it.

We have in other places created small helpers that send the events to avoid including `jfrEvents.hpp` all over the place, and we could to that here as well. But I don't see a problem with having the reporter residing along side the other reporters.

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

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