RFR: 8157023: Integrate NMT with JFR [v4]

Markus Grönlund mgronlun at openjdk.org
Wed Dec 7 13:50:06 UTC 2022


On Tue, 6 Dec 2022 16:42:54 GMT, Stefan Johansson <sjohanss 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
>
> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename the files
>  - Renaming and updating comments
>  - tstuefe review - no rename

src/hotspot/share/jfr/metadata/metadata.xml line 711:

> 709:   <Event name="NativeMemoryUsage" category="Java Virtual Machine, Memory" label="Native Memory Usage Per Type"
> 710:     description="Native memory usage for a given memory type in the JVM" period="everyChunk">
> 711:     <Field type="string" name="type" label="Memory Type" description="Type used for the native memory allocation" />

Suggest turning this type "string" into a JFR-constant type, like "JfrNMTType" to only send id's, instead of the entire strings. Can be done in a follow-up change.

src/hotspot/share/services/memJfrReporter.cpp line 67:

> 65:   Ticks timestamp = MemJFRCurrentUsage::get_timestamp();
> 66: 
> 67:   EventNativeMemoryUsageTotal event;

Since you are explicitly setting the startTime field yourself, you can pass 'UNTIMED' to the event constructor. This will bypass the automatic setting of _starttime as part of the constructor.

EventNativeMemoryUsageTotal event(UNTIMED);

src/hotspot/share/services/memJfrReporter.cpp line 75:

> 73: 
> 74: void MemJFRReporter::send_type_event(const Ticks& starttime, const char* type, size_t reserved, size_t committed) {
> 75:   EventNativeMemoryUsage event;

Since you are explicitly setting the startTime field yourself, you can pass 'UNTIMED' to the event constructor. This will bypass the automatic setting of _starttime as part of the constructor.

EventNativeMemoryUsage event(UNTIMED);

src/hotspot/share/services/memJfrReporter.hpp line 45:

> 43: // Helper class to avoid refreshing the NMTUsage to often and allow
> 44: // the two JFR events to use the same data.
> 45: class MemJFRCurrentUsage : public AllStatic {

Move to .cpp file to because only used internally. Does not even have to be a class, can only be static fields and accessors.

src/jdk.jfr/share/conf/jfr/default.jfc line 516:

> 514: 
> 515:     <event name="jdk.NativeMemoryUsage">
> 516:       <setting name="enabled" control="gc-enabled-normal">true</setting>

gc-enabled-normal? Should this really be tied to a gc control? An NMT control to be introduced?

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

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


More information about the hotspot-dev mailing list