Thursday, May 9, 2013
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:
C:\Users\kh1205>jps
3596
6616 Jps
1720 Main
Finding stack size:
C:\Users\kh1205>jinfo -flag ThreadStackSize 1720
-XX:ThreadStackSize=4096
>java -XX:+PrintFlagsFinal
This display all the startup parameters in the console.
To display the process ID:
C:\Users\kh1205>jps
3596
6616 Jps
1720 Main
Finding stack size:
C:\Users\kh1205>jinfo -flag ThreadStackSize 1720
-XX:ThreadStackSize=4096
4096 represents stack size in KB = 4 MB, which i have configured through
-Xss4096K in VM arguments.
Default settings for the JVM
Info @ http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.user.lnx.60%2Fdiag%2Fappendixes%2Fdefaults.html
| JVM setting | AIX® | IBM® i | Linux | Windows | z/OS® | Setting affected by |
|---|---|---|---|---|---|---|
| Default locale | None | None | None | N/A | None | e |
| Time to wait before starting plug-in | N/A | N/A | Zero | N/A | N/A | e |
| Temporary directory | /tmp | /tmp | /tmp | c:\temp | /tmp | e |
| Plug-in redirection | None | None | None | N/A | None | e |
| IM switching | Disabled | Disabled | Disabled | N/A | Disabled | e |
| IM modifiers | Disabled | Disabled | Disabled | N/A | Disabled | e |
| Thread model | N/A | N/A | N/A | N/A | Native | e |
| Initial stack size for Java™ Threads 32-bit. Use:-Xiss<size> | 2 KB | 2 KB | 2 KB | 2 KB | 2 KB | c |
| Maximum stack size for Java Threads 32-bit. Use: -Xss<size> | 256 KB | 256 KB | 256 KB | 256 KB | 256 KB | c |
| Stack size for OS Threads 32-bit. Use-Xmso<size> | 256 KB | 256 KB | 256 KB | 32 KB | 256 KB | c |
| Initial stack size for Java Threads 64-bit. Use:-Xiss<size> | 2 KB | N/A | 2 KB | 2 KB | 2 KB | c |
| Maximum stack size for Java Threads 64-bit. Use: -Xss<size> | 512 KB | N/A | 512 KB | 512 KB | 512 KB | c |
| Stack size for OS Threads 64-bit. Use-Xmso<size> | 256 KB | N/A | 256 KB | 256 KB | 256 KB | c |
| Initial heap size. Use -Xms<size> | 4 MB | 4 MB | 4 MB | 4 MB | 4 MB | c |
| Maximum Java heap size. Use -Xmx<size> | Half the available memory with a minimum of 16 MB and a maximum of 512 MB | 2 GB | Half the available memory with a minimum of 16 MB and a maximum of 512 MB | Half the real memory with a minimum of 16 MB and a maximum of 2 GB | Half the available memory with a minimum of 16 MB and a maximum of 512 MB | c |
Setting stack size to a Java thread
From JavaDoc
Allocates a new
This constructor is identical to
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
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.
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.
- Parameters:
- group the thread group.
- target the object whose
runmethod 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.
- Throws:
- SecurityException - if the current thread cannot create a thread in the specified thread group.
- Since:
- 1.4
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:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/f097ca2434b1/src/share/bin/java.c
lines 1052 - 1058,
and the VM part:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/runtime/arguments.cpp
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:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/prims/jni.cpp,
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: http://bugs.sun.com/view_bug.do?bug_id=6316197.
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@ http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-June/004272.html
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.
-Xss4096K
more info @http://www.onkarjoshi.com/blog/209/using-xss-to-adjust-java-default-thread-stack-size-to-save-memory-and-prevent-stackoverflowerror/comment-page-1/#comment-135809
Subscribe to:
Posts (Atom)