JVM Tutorials - Herong's Tutorial Examples - Version 4.23, by Dr. Herong Yang
Largest Stack Size for JRockit on Windows
This section provides a tutorial example on how to find out the largest stack size supported by JRockit on Windows systems. The highest safe stack size is about 32 MB on Windows.
If we want to find out the largest stack size JRockit can support, we can keep increasing the stack size using the -Xss option on MultiStackThread.java with 1 thread.
My test results are summarized below together with results from HotSpot:
HotSpot 1.8 | JRockit R28 -Xss Frames Mem Usage Heap Usage | Frames Mem Usage Heap Usage 1m 17939 15,064 K 566128 | 86596 23,184 K 4366928 2m 27970 16,256 K 547728 | 130286 24,532 K 4716456 4m 50763 18,260 K 584744 | 217668 27,272 K 5415504 8m 94906 18,680 K 570872 | 392430 33,096 K 6813608 16m 182579 26,896 K 570872 | 741956 44,184 K 9609808 32m 356072 43,300 K 570872 | 1441006 66,120 K 15202216 64m 704467 76,112 K 552088 | 2839108 110,544 K 26387024 128m 1403726 141,768 K 570808 | (Unable to stop with Ctrl-C) 160m 1754577 174,620 K 552200 176m 1929494 191,028 K 552248
Obviously, HotSpot 1.8 is doing much better that JRockit R28 in JVM footprint and heap memory usage:
1. HotSpot expands its footprint just enough to meet the need of the single expanding stack.
JRockit expands its footprint must more than the need of the single expanding stack. For example, with a full stack of 32 MB, JRockit's footprint is 66 MB. A large portion of memory is wasted.
2. HotSpot uses no heap memory to support large stack size and large number of frames.
JRockit uses a large chunk of heap memory to support large stack size and large number of frames. For example, with a full stack of 32 MB, JRockit uses about 15 MB heap memory.
But JRockit uses smaller frames and supports more frames. With my sample thread, MultiStackThread.java, JRockit frame size is 4 times smaller than HotSpot. In other words, JRockit supports 4 times more frames than HotSpot.
Note that when the stack reaches its 64 MB limit, the JVM gives the following error when I tried to break it with <Ctrl-C>:
[ERROR][thread ] Could not start thread SIGINT handler. Not enough storage is available to process this command [ERROR][jrockit] Exception occured in registered Java signal handler: java.lang.OutOfMemoryError: Not enough storage is available to process this command in tsStartJavaThread (src/jvm/threads/vmthread/lifecycle.c:1097). Attempting to allocate 1G bytes There is insufficient native memory for the Java Runtime Environment to continue. 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) Disable compressed references (-XXcompressedRefs=false) at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) at sun.misc.Signal.dispatch(Signal.java:199)
Last update: 2014.
Table of Contents