Thursday, May 9, 2013

OutOfMemoryError: unable to create new native thread

Startup parameters of JVM and stacksize

Display all startup parameters:

>java -XX:+PrintFlagsFinal

This display all the startup parameters in the console.

To display the process ID:

6616 Jps
1720 Main

Finding stack size:

C:\Users\kh1205>jinfo -flag ThreadStackSize  1720

4096 represents stack size in KB = 4 MB, which i have configured through 
-Xss4096K in VM arguments.

Default settings for the JVM

Info @

JVM settingAIX®IBM® iLinuxWindowsz/OS®Setting affected by
Default localeNoneNoneNoneN/ANonee
Time to wait before starting plug-inN/AN/AZeroN/AN/Ae
Temporary directory/tmp/tmp/tmpc:\temp/tmpe
Plug-in redirectionNoneNoneNoneN/ANonee
IM switchingDisabledDisabledDisabledN/ADisablede
IM modifiersDisabledDisabledDisabledN/ADisablede
Thread modelN/AN/AN/AN/ANativee
Initial stack size for Java™ Threads 32-bit. Use:-Xiss<size>2 KB2 KB2 KB2 KB2 KBc
Maximum stack size for Java Threads 32-bit. Use: -Xss<size>256 KB256 KB256 KB256 KB256 KBc
Stack size for OS Threads 32-bit. Use-Xmso<size>256 KB256 KB256 KB32 KB256 KBc
Initial stack size for Java Threads 64-bit. Use:-Xiss<size>2 KBN/A2 KB2 KB2 KBc
Maximum stack size for Java Threads 64-bit. Use: -Xss<size>512 KBN/A512 KB512 KB512 KBc
Stack size for OS Threads 64-bit. Use-Xmso<size>256 KBN/A256 KB256 KB256 KBc
Initial heap size. Use -Xms<size>4 MB4 MB4 MB4 MB4 MBc
Maximum Java heap size. Use -Xmx<size>Half the available memory with a minimum of 16 MB and a maximum of 512 MB2 GBHalf the available memory with a minimum of 16 MB and a maximum of 512 MBHalf the real memory with a minimum of 16 MB and a maximum of 2 GBHalf the available memory with a minimum of 16 MB and a maximum of 512 MBc

Setting stack size to a Java thread

 From JavaDoc

java.lang.Thread.Thread(ThreadGroup group, Runnable target, String name, long stackSize)

Allocates a new Thread object so that it has target as its run object, has the specified name as its name, belongs to the thread group referred to by group, and has the specified stack size.
This constructor is identical to Thread(ThreadGroup, Runnable, String) with the exception of the fact that it allows the thread stack size to be specified. The stack size is the approximate number of bytes of address space that the virtual machine is to allocate for this thread's stack.

The effect of the stackSize parameter, if any, is highly platform dependent.
On some platforms, specifying a higher value for the stackSize parameter may allow a thread to achieve greater recursion depth before throwing a StackOverflowError. Similarly, specifying a lower value may allow a greater number of threads to exist concurrently without throwing an OutOfMemoryError (or other internal error). The details of the relationship between the value of the stackSize parameter and the maximum recursion depth and concurrency level are platform-dependent. On some platforms, the value of the stackSize parameter may have no effect whatsoever.
The virtual machine is free to treat the stackSize parameter as a suggestion. If the specified value is unreasonably low for the platform, the virtual machine may instead use some platform-specific minimum value; if the specified value is unreasonably high, the virtual machine may instead use some platform-specific maximum. Likewise, the virtual machine is free to round the specified value up or down as it sees fit (or to ignore it completely).

Specifying a value of zero for the stackSize parameter will cause this constructor to behave exactly like the Thread(ThreadGroup, Runnable, String) constructor.

Due to the platform-dependent nature of the behavior of this constructor, extreme care should be exercised in its use. The thread stack size necessary to perform a given computation will likely vary from one JRE implementation to another. In light of this variation, careful tuning of the stack size parameter may be required, and the tuning may need to be repeated for each JRE implementation on which an application is to run.
Implementation note: Java platform implementers are encouraged to document their implementation's behavior with respect to the stackSize parameter.
group the thread group.
target the object whose run method is called.
name the name of the new thread.
stackSize the desired stack size for the new thread, or zero to indicate that this parameter is to be ignored.
SecurityException - if the current thread cannot create a thread in the specified thread group.

What the difference between -Xss and -XX:ThreadStackSize ?

There's basically no difference between -Xss and -XX:ThreadStackSize, except
that the former dates before HotSpot became the default JVM in Sun's JDK,
where as the latter is an internal VM flag of HotSpot. In effect, the former
is support in a lot of other JVMs, but the latter is specific to HotSpot.

As an historical aside, the command line arguments for Sun JDK 1.0.x and
1.1.x had these:
-ss<number>       set the C stack size of a process
-oss<number>      set the JAVA stack size of a process

These arguments got deprecated by -Xss and -Xoss in later versions of JDK.

Non-internal flags either get processd by the java launcher (such as
-server, -client, -verbosegc, etc.) or get converted into VM internal flags
by HotSpot. See hotspot/src/share/vm/runtime/arguments.cpp for details.

For example, see this version:
the launcher part:
lines 1052 - 1058,
and the VM part:
lines 2227 - 2240.

As you can see, -Xss gets converted into ThreadStackSize before the VM gets
to use it.
If the user did specify -ss or -Xss in command line arguments, that'll get
picked up directly by the launcher to run the main Java thread. Otherwise,
the launcher asks the VM for a preferred stack size, and HotSpot will return
ThreadStackSize, see here:,
lines 3286 - 3295.

That should explain how they've been implemented to be basically equivalent
in HotSpot.

One thing, though: because the -Xss/-XX:ThreadStackSize argument is handled
by the VM, *after* the primordial thread has been created, so they won't
cover the stack size of the primordial thread. In order to control stack
size correctly, Oracle/Sun's JDK doesn't run Java code in the primordial
thread. See this bug:
If you ever felt the function "ContinueInNewThread" in the launcher was
weird, that's the fix for this issue, so that Java code doesn't get run in
the primordial thread in HotSpot.

resource from@

Changing the default Java Stack size for JVM

In VM arguments, pass the following parameter.

Example: I want to change it to 4MB as my JVM stacksize.


more info @

Get thread stack size at runtime

jinfo -flag ThreadStackSize PID

resource @