java.lang.OutOfMemoryError: unable to create new native thread

One of the developer reported "java.lang.OutOfMemoryError: unable to create new native thread" while working with eclipse on his application.

Below is the error log.

java.lang.OutOfMemoryError: unable to create new native thread

                at java.lang.Thread.start0(Native Method)

                at java.lang.Thread.start(Unknown Source)

                at java.lang.ref.Finalizer$1.run(Unknown Source)

                at java.security.AccessController.doPrivileged(Native Method)

                at java.lang.ref.Finalizer.forkSecondaryFinalizer(Unknown Source)

                at java.lang.ref.Finalizer.runFinalization(Unknown Source)

                at java.lang.Runtime.runFinalization0(Native Method)

                at java.lang.Runtime.runFinalization(Unknown Source)

                at java.lang.System.runFinalization(Unknown Source)

                at org.eclipse.ui.internal.ide.application.IDEIdleHelper$3.run(IDEIdleHelper.java:182)

                at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

This is what i can think why he encountered with this issue.

User is running on 32 bit machine with 

Since he is running on 32 bit machine, you need to allocate –Xmx and -XX:PermSize carefully. Since 32 bit machines can address maximum of 4GB address space.

Since we allocated -Xmx is 1024m and -XX:PermSize is 512m, there is very less space is remaining to create a new Java native threads by OS.

To make it work, reduce -XX:PermSize to 256m and –Xmx to 512m(unless 1024 is required).

UseCompressedOops flag with java

Recently one of colleague was unable to launch eclipse, it says ‘Java returned with exit code =1’ , we have tried lot of options by increasing heap memory and all, but finally what worked out for him was by setting a  UseCompressedOops flag in eclipse configuration file.

He was using 64 bit machine and 64 bit JVM.

Here is the story, what compressed flag does.

The -XX:+UseCompressedOops option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process.

Compressed oops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, use of compressed oops is the default for 64-bit JVM processes when -Xmx isn't specified and for values of -Xmx less than 32 gigabytes. For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature.

In summary:

Java version <6u23 - use command to set it.

Java version >=6u23 - by default enabled.

JDK7 - if -xmx not specified or -xmx <32GB => configured bydefault

You might have a question how does 64 bit pointer fits into 32 bit pointer, how it will be compressed. Please go through below link to understand more about it.

http://www.ibm.com/developerworks/opensource/library/j-codetoheap/index.html

This is how JRocket JVM is compressing it, this will give us some understanding.

https://blogs.oracle.com/jrockit/entry/understanding_compressed_refer

https://wikis.oracle.com/display/HotSpotInternals/CompressedOops

Java code to Java Heap

This is an excellent article which describes how Java 32 bit and 64 bit processes works with various primitives and objects in Java.

http://www.ibm.com/developerworks/opensource/library/j-codetoheap/index.html

Java VM PermGen space

The Java VM memory is split up to 3 memory spaces:

• The Java Heap. Applicable for all JVM vendors, usually split between YoungGen (nursery) & OldGen (tenured) spaces.
• The PermGen (permanent generation). Applicable to the Sun HotSpot VM only (PermGen space will be removed in future Java 7 or Java 8 updates)
• The Native Heap (C-Heap). Applicable for all JVM vendors.

The Java HotSpot VM permanent generation space is the JVM storage used mainly to store your Java Class objects.  The Java Heap is the primary storage that is storing the actual short and long term instances of your PermGen Class objects.

The PermGen space is fairly static by nature unless using third party tool and/or Java Reflection API which relies heavily on dynamic class loading.

It is important to note that this memory storage is applicable only for a Java HotSpot VM; other JVM vendors such as IBM and Oracle JRockit do not have such fixed and configurable PermGen storage and are using other techniques to manage the non Java Heap memory (native memory).

Below diagram showcases various heap memories and how we can configure them using vm arguments.