Search code examples
multithreadingjava-8java-native-interfacenativejava-7

private bytes increase for a javaw process in java 8

My project has started using java 8 from java 7.

After switching to java 8, we are seeing issues like the memory consumed is getting higher with time.

Here are the investigations that we have done :

  • Issues comes only after migrating from java7 and from java8
  • As metaspace is the only thing related to memory which is changes from hava 7 to java 8. We monitored metaspace and this does not grow more then 20 MB.
  • Heap also remains consistent.

Now the only path left is to analyze how the memory gets distributes to process in java 7 and java 8, specifically private byte memory. Any thoughts or links here would be appreciated.

NOTE: this javaw application is a swing based application.

UPDATE 1 : After analyzing the native memory with NMT tool and generated a diff of memory occupied as compare to baseline. We found that the heap remained same but threads are leaking all this memory. So as no change in Heap, I am assuming that this leak is because of native code.

So challenge remains still open. Any thoughts on how to analyze the memory occupied by all the threads will be helpful here. Below are the snapshots taken from native memory tracking.

In this pic, you can see that 88 MB got increased in threads. Where arena and resource handle count had increased a lot.

enter image description here

in this picture you can see that 73 MB had increased in this Malloc. But no method name is shown here. enter image description here

So please throw some info in understanding these 2 screenshot.

Solution

  • I encountered the exact same issue.

    Heap usage constant, only metaspace increase, NMT diffs showed a slow but steady leak in the memory used by threads specifically in the arena allocation. I had tried to fix it by setting the MALLOC_ARENAS_MAX=1 env var but that was not fruitful. Profiling native memory allocation with jemalloc/jeprof showed no leakage that could be attributed to client code, pointing instead to a JDK issue as the only smoking gun there was the memory leak due to malloc calls which, in theory, should be from JVM code.

    Like you, I found that upgrading the JDK fixed the problem. The reason I am posting an answer here is because I know the reason it fixes the issue - it's a JDK bug that was fixed in JDK8 u152: https://bugs.openjdk.java.net/browse/JDK-8164293

    The bug report mentions Class/malloc increase, not Thread/arena, but a bit further down one of the comments clarifies that the bug reproduction clearly shows increase in Thread/arena.