JRockit Running Out Of Memory Quicker

This section provides a tutorial example on how to test when JRockit JVM runs out of memory by increasing the number of threads with full stacks. JRockit JVM returns OutOfMemoryError exception before reaching 1 GB memory usage lower than HotSpot.

Now let's keep the number of frames with a high number to let the thread to reach the stack overflow point, and increase the number of threads to see when the JRockit JVM will run out of memory.

The results are summarized and listed below together with results from the HotSpot tests: Let's try it:

          HotSpot 1.8   JRockit R28
Threads    Mem Usage     Mem Usage     (-Xss1m, 100000 frames)
      1     15,008 K      23,476 K
      4     18,248 K      32,040 K
     16     33,352 K      65,720 K
     32     51,336 K     109,460 K
     64     84,380 K     280,868 K
    128    150,264 K     335,708 K
    256    278,684 K     609,460 K
    512    541,932 K     OutOfMemoryError    
   1024  1,072,008 K  
   2048  OutOfMemoryError

As you can see from the output:

When I ran 512 threads with 100000 frames, many threads reached the StackOverflow exception point and the JVM memory usage reached 966,064 K. Then the JVM hang after generating the following exception:

[ERROR][thread ] Could not start thread Thread-428. 
   Not enough storage is available to process this command
Stack overflow at 32447 for thread: 437
Exception in thread "Main Thread" 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)
Stack overflow at 32531 for thread: 438

Looks like JRockit JVM on 32-bit Windows can only support up to 1 GB of memory.

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