Native Memory May Cause Unknown Memory Leaks
Recently I came across a strange case: the memory usage of my program exceeded the maximum value intended for the heap. I found an interesting issue.
Join the DZone community and get the full member experience.Join For Free
Recently I came across a strange case: the memory usage of my program exceeded the maximum value intended for the heap. Even after running GC, part of the memory was not free. I already knew that a part of JVM memory would be allocated to native memory and part of native memory allocated to C code, but I did not have even one line of native code in my program. After reviewing and profiling my code several times, I found an interesting issue. Before diving into the problem, let's look at Java memory concepts.
Memory Management in Java
JVM divides memory into two major spaces, heap and native memory. Heap spaces are used for allocating Java objects whereas native memory is the memory available to the OS. There is a key difference between Java 7 and 8 in the memory management model. Java 7 has PermGen; PermGen is the memory area in the heap that is used by the JVM to store class metadata, static content, primitive variables. Java 8 has eliminated PermGen and added Metaspace; actually, Metaspace and PermGen do the same thing. The main difference is that PermGen is part of the Java heap while Metaspace is NOT part of the heap. Rather Metaspace is part of native memory, which is only limited by the Host Operating System.
Native memory is a memory area outside the normal JVM heap but generally is a part of total memory spared by OS for the JVM process. Part of native memory is assigned to the C heap; the C heap is space that used by native C programs in Java programs.
Native Memory Tracking (NMT)
NMT is a memory tracking tool used to monitor the native memory usage of the program. You can access NMT data using jcmd utility. NMT is not enabled by default; you can enable it by adding the following parameters to JVM options:
For monitoring and tracking memory changes during execution you should use the following command:
<pid> is the exact process id of your Java program in Linux. In my case my <pid> is '92165' so I executed this command:
Consider that monitoring is a time-based approach it means that you should compare memory state in time T2 with the state in time T1, so you need to mark the state of T1 as a baseline by using the following command:
I also executed these commands in chronological order:
DEC 19, 2020 9:07:10 AM IRS :
jcmd 92165 VM.native_memory baseline
DEC 19, 2020 12:07:10 PM IRS:
jcmd 92165 VM.native_memory detail.diff.
The output of that was something like this:
reserved 3892 KB for Thread Stack from [Thread::record_stack_base_and_size()+0xca] [0x9f586000 - 0x9f791000] reserved 1680KB for Thread Stack from [Thread::record_stack_base_and_size()+0xca]
I tried to execute the command
jcmd 92165 VM.native_memory detail.diff at different times, and I was getting different results every moment, which means that my native memory usage is growing over time.
So, What's the Problem?!
In the previous part, I said my native memory grows over time, and I was sure I have no native code in my program, but then what is the problem? I started tracing the program at the same time as monitoring, and I found an interesting thing: there was a usage of java.util.zip code in the program. Once I reached this code the usage of native memory increased significantly. The problem was clear; this package classes internally and uses native codes. If you take a look at JDK source at jdk8 source, you can find interesting codes like this, implementations of certain classes based on native codes and C:
Remember that native codes are not just in these classes. There are a lot of components, like components that interact with devices or communication components, that potentially use native codes.
Opinions expressed by DZone contributors are their own.