JRockit Frame Size Smaller than HotSpot

This section provides a tutorial example on comparing the frame size between JRockit and HotSpot JVMs. The JRockit frame size is 8 bytes for a simple method call comparing to 32 bytes for HotSpot.

To find out the frame size used by JRockit, we are going to take the similar approach used in previous tutorials. We will run the StackOverflowTest.java with different stack size, let JRockit to reach the StackOverflowError exception and count the number of nested calls (frames) in the stack.

The results summarized and listed together with test results from HotSpot

 -Xss     HotSpot 1.8       JRockit R28
Stack   Frames   Frame    Frames   Frame
 Size             Size              Size
128k      2505   52.32     14772    8.87
256k      6327   41.44     31156    8.41
304k      8295   37.53     39348    7.91
512k     14339   36.57     63924    8.20
  1m     30738   34.11    129460    8.10
 64m   2095152   32.03   8386996    8.00   
128m   4192607   32.01   Failed to start

This result clearly indicates that the frame size is 8 bytes for JRockit to execute the following method:

   private static void sub() {
      n++;
      sub();
   }

So is JRockit JVM doing a better job to optimized the frame usage? JRockit uses only 8 bytes, much smaller than 32 bytes used by HotSpot.

Also note that when running with -Xss128m, JRockit R28 fails to start and give the following message:

[ERROR][thread ] Could not start thread (GC Worker Thread 4). 
   Not enough storage is available to process this command
[ERROR] Can not initialize starting GC threads.
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)
Could not create the Java virtual machine.

To understand this error, we need to measure the footprint of JRockit JVM. See next tutorial for details.

Last update: 2014.

Table of Contents

 About This Book

 Downloading and Installing JDK 1.8.0 on Windows

 Downloading and Installing JDK 1.7.0 on Windows

 java.lang.Runtime Class - The JVM Instance

 java.lang.System Class - The Operating System

 ClassLoader Class - Class Loaders

 Class Class - Class Reflections

 Sun's JVM - Java HotSpot VM

 JRockit JVM 28.2.7 by Oracle Corporation

 JVM Runtime Data Areas

 Memory Management and Garbage Collectors

 Garbage Collection Tests

JVM Stack, Frame and Stack Overflow

 What Is JVM Stack?

 StackOverflowError Exception Test

 -Xss JVM Option for Stack Size

 Frame Impact of Extra Statements

 JVM Stack Expansion and Footprint

 JVM Stack Expansion and OutOfMemoryError

 Largest Stack Size for HotSpot on Windows

 Default Stack Sizes of HotSpot and JRockit

JRockit Frame Size Smaller than HotSpot

 JRockit Expanding Stacks in Bigger Chunks

 JRockit Running Out Of Memory Quicker

 Largest Stack Size for JRockit on Windows

 Thread Testing Program and Result

 CPU Impact of Multi-Thread Applications

 I/O Impact of Multi-Thread Applications

 CDS (Class Data Sharing)

 Micro Benchmark Runner and JVM Options

 Micro Benchmark Tests on "int" Operations

 Micro Benchmark Tests on "long" Operations

 Micro Benchmark Tests in JIT Compilation Mode

 Micro Benchmark Tests on "float" and "double" Operations

 Outdated Tutorials

 References

 PDF Printing Version