JVM Native memory leak

The Problem

There are times I learn something new of something that has been known since ages. Today was one of those times. Had a  Java Virtual Machine (JVM) whose heap usage looked great but the JVM process ended up growing native memory and finally died with an exception stating unable to allocate native memory. One such example might look like:

java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:450) 

Or

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 184 bytes for AllocateHeap
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.

The application in question that manifested the above is a simple jersey web service that serves up and consumes JSON using JSON JAXB (Clue...). Initial interrogation yielded the following:

• Thread usage is normal (-Xss settings has no benefit)
•  –XXMaxDirectMemorySize - No difference
• Heap usage is healthy
• Heap dumps look healthy - no leaks
• Perm Gen is looking good
• Native file descriptors are within normal usage limits
• java.net.Socket creation did not appear to cause issues
• JDK version latest (1.7.X)
• Happens on Virtual machines or stand alone boxes

Some Stack Overflow and other assistance:

• http://stackoverflow.com/questions/10329546/java-process-memory-usage-much-more-than-what-runtime-totalmemory-et-al-methods
• http://stackoverflow.com/questions/4893192/process-memory-vs-heap-jvm
• http://www.oracle.com/technetwork/java/javase/memleaks-137499.html

What fixed the issue - 

• Using the G1 Garbage collector
• Or Setting Xms and Xmx to smaller values, i.e., lowering heap size

Right, so using G1 Garbage collector worked, or setting max heap to a lower value also worked? WTF!

What happened?

Creation of  a JAXB Context on every request/response. The application in question was not caching JAXB Contexts but was creating them on every request/response. Initial thought is, yeah, that is a performance problem, but why will it count towards native process memory growth? Consider the following benign code:

public class SimpleTest extends Thread { 
  public void run() {
    while (!Thread.currentThread().isInterrupted()) {
      JSONJAXBContext context = new JSONJAXBContext(SomeDTOClass.class); // From jersey-json.jar
    }
  }

  public static void main(String args[]) {
    new SimpleTest().start();
  }
} 

Well, the problem is that JAXB Contexts indirectly involve in the invoking of native memory allocations. How does it do it and what happens underneath? Well, that is an exercise for the reader to figure out and comment on this BLOG with findings ;-).

The root cause can be dialed down to the following issue posted: http://bugs.java.com/view_bug.do?bug_id=4797189

public class Bug {
  public static void main( String args[] ) {
    while ( true ) {
      /* If ANY of these two lines is not commented, the JVM runs out of memory */
      final Deflater deflater = new Deflater( 9, true );
      final Inflater inflater = new Inflater( true );
    }
 }
}

The same code that might work without native OOM:

public class Bug {
  public static void main( String args[] ) {
    int count = 0;
    while ( true ) {
      final Deflater deflater = new Deflater( 9, true );
      final Inflater inflater = new Inflater( true );
      i++;
      if (i % 100 == 0) {
       System.gc(); // Don't, please don't do this!
      }
    }
 }
}

As shown above, you might allocate 'small' objects in the JVM but underneath they might end up allocating native memory for their operations. The intention is noble, that when the objects are finalized, the native operating system memory will be de-allocated as well. However, the freeing of the native memory is contingent on the Garbage collector running and leading to finalization of these 'small' objects. Its a matter of relative pace, the native memory is growing far faster compared to JVM heap and the lack of Garbage collection occurring is what leads to running out of native space. When using the G1 collector or lowering max heap settings, garbage collection occurs more often, thus preventing the native heap from exploding over time.

Peace!