The Native Memory Tracking (NMT) is a Java HotSpot VM feature that tracks internal memory usage for a Java HotSpot VM. For details about NMT scope, how to enable NMT, and other additional usage details, see Native Memory Tracking.
Since NMT doesn't track memory allocations by non-JVM code, you may have to use tools supported by the operating system to detect memory leaks in native code.
The following sections describe how to monitor VM internal memory allocations and diagnose VM memory leaks.
Follow these steps to detect a memory leak.
Start the JVM with summary or detail tracking using the command line option: -XX:NativeMemoryTracking=summary or -XX:NativeMemoryTracking=detail.
Establish an early baseline - use NMT baseline feature to get a baseline to compare during development and maintenance by running: jcmd <pid> VM.native_memory baseline.
Monitor memory changes using: jcmd <pid> VM.native_memory detail.diff.
If the application leaks a small amount of memory, it make take a while to show up.
Used with The jcmd Utility, Native Memory Tracking can be set up to monitor memory and ensure that an application does not start to use increasing amounts of memory during development or maintenance. See Table 2-1 for details about NMT memory categories.
The following sections describe how to get summary or detail data for NMT and describes how to interpret the sample output.
Interpret sample output: From the sample output below, you will see reserved and committed memory. Note that only committed memory is actually used. For example, if you run with -Xms100m -Xmx1000m, the JVM will reserve 1000 MB for the Java Heap. Since the initial heap size is only 100 MB, only 100MB will be committed to begin with. For a 64-bit machine where address space is almost unlimited, there is no problem if a JVM reserves a lot of memory. The problem arises if more and more memory gets committed, which may lead to swapping or native OOM situations.
Arena is a chunk of memory allocated using malloc. Memory is freed from these chunks in bulk, when exiting a scope or leaving an area of code. These chunks may be reused in other subsystems to hold temporary memory, for example, pre-thread allocations. Arena malloc policy ensures no memory leakage. So Arena is tracked as a whole and not individual objects. Some amount of initial memory can not by tracked.
Enabling NMT will result in a 5-10 percent JVM performance drop and memory usage for NMT adds 2 machine words to all malloc memory as malloc header. NMT memory usage is also tracked by NMT.
Get summary data: To get a summary view of native memory usage, start the JVM with command line option: -XX:NativeMemoryTracking=summary.
Example 2-2 is a sample output that describes NMT for track level set to summary. One way to get this sample output is to run: jcmd <pid> VM.native_memory summary.
Get detail data: To get a more detailed view of native memory usage, start the JVM with command line option: -XX:NativeMemoryTracking=detail. This will track exactly what methods allocate the most memory. Enabling NMT will result in 5-10 percent JVM performance drop and memory usage for NMT adds 2 words to all malloc memory as malloc header. NMT memory usage is also tracked by NMT.
Example 2-3 shows a sample output for virtual memory for track level set to detail. One way to get this sample output is to run: jcmd <pid> VM.native_memory detail.
Get diff from NMT baseline: For both summary and detail level tracking, you can set baseline once the application is up and running. Do this by running jcmd <pid> VM.native_memory baseline after some warm up of the application. Then, you can run: jcmd <pid> VM.native_memory summary.diff or jcmd <pid> VM.native_memory detail.diff.
Example 2-4 shows a sample output for the summary difference in native memory usage since the baseline and is a great way to find memory leaks.
Example 2-5 is a sample output that shows the detail difference in native memory usage since the baseline and is a great way to find memory leaks.
