Native Memory Investigation

Flags

-XX:NativeMemoryTracking=summary records native memory categories. With -XX:+PrintNMTStatistics, the JVM prints a summary at exit so you can see memory used by metaspace, code cache, GC, compiler, threads, and internal structures.

Flag details

-XX:NativeMemoryTracking=summary

Enables category-level accounting for JVM native memory. This is usually enough to see whether memory is going to threads, class metadata, code cache, GC, compiler, or internal allocations.

-XX:NativeMemoryTracking=detail

Collects more detailed native allocation information. It is more expensive and is best for targeted investigations.

-XX:+PrintNMTStatistics

Prints NMT data when the JVM exits, which is useful for batch jobs or reproductions where you want a final memory summary.

When to use it

Use this when RSS is much larger than -Xmx, especially with Netty, JNI, direct buffers, many threads, class loading churn, or container memory pressure.

Java version support

Native Memory Tracking is a HotSpot diagnostic facility available across the modern JDKs in this catalog. Use summary for lower-overhead investigations and detail when you need more allocation-site information.

Related JEPs

• Native Memory Tracking does not have a dedicated feature JEP; it is part of HotSpot serviceability diagnostics.

Examples

java -XX:NativeMemoryTracking=summary \
  -XX:+PrintNMTStatistics \
  -jar app.jar

Use summary mode first for production-like investigations.

java -XX:NativeMemoryTracking=detail \
  -jar app.jar

Use detail mode only when summary mode shows the problem but not enough location detail.

Verify

Use jcmd <pid> VM.native_memory summary during runtime and compare the result with OS-level RSS.