Performance Zone is brought to you in partnership with:

Pierre-Hugues Charbonneau (nickname P-H) is working for CGI Inc. Canada for the last 10 years as a senior IT consultant and system architect. His primary area of expertise is Java EE, middleware & JVM technologies. He is a specialist in production system troubleshooting, middleware & JVM tuning and scalability / capacity improvement; including processes improvement for Java EE support teams. Pierre - Hugues is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Java Heap Space – JRockit VM

  • submit to reddit

This article will provide you with an overview of the JRockit Java Heap Space vs. the HotSpot VM. It will also provide you some background on Oracle future plans regarding JRockit & HotSpot.

Oracle JRockit VM Java Heap: 2 different memory spaces
The JRockit VM memory is split between 2 memory spaces:
  •      The Java Heap (YoungGen and OldGen)
  •      The Native memory space (Classes pool, C-Heap, Threads...)

Memory Space Start-up arguments and tuning Monitoring strategies Description
Java Heap -Xmx (maximum Heap space)
-Xms (minimum Heap size)
EX: -Xmx1024m -Xms1024m
- verbose GC - JMX API - JRockit Mission Control tools suite The JRockit Java Heap is typically split between the YoungGen (short-lived objects), OldGen (long-lived objects).

Native memory space Not configurable directly.
For a 32-bit VM, the native memory space capacity = 2-4 Gig – Java Heap 

** Process size limit of 2 GB, 3 GB or 4 GB depending of your OS **
For a 64-bit VM, the native memory space capacity = Physical server total RAM & virtual memory – Java Heap
- Total process size check in Windows and Linux - pmap command on Solaris & Linux
- JRockit JRCMD tool
The JRockit Native memory space is storing the Java Classes metadata, Threads and objects such as library files, other JVM and third party native code objects.

Where is the PermGen space?
Similar to the IBM VM, there is no PermGen space for the JRockit VM. The PermGen space is only applicable to the HotSpot VM. The JRockit VM is using the Native Heap for Class metadata related data. Also, as you probably saw from my other article, Oracle Sun is also starting to remove the PermGen space for the HotSpot VM.
Why is the JRockit VM Java process using more memory than HotSpot VM?
The JRockit VM tend to uses more native memory in exchange for better performance. JRockit does not have an interpretation mode, compilation only, so due to its additional native memory needs the process size tends to use a couple of hundred MB larger than the equivalent Sun JVM size. This should not be a big problem unless you are using a 32-bit JRockit with a large Java Heap requirement; in this scenario, the risk of OutOfMemoryError due to Native Heap depletion is higher for a JRockit VM (e.g. for a 32-bit VM, bigger is the Java Heap, smaller is memory left for the Native Heap).
What is Oracle’s plan for JRockit?
Current Oracle JVM strategy is to merge both HotSpot and JRockit product lines to a single JVM project that will include the best features of each VM. This will also simplify JVM tuning since right now failure to understand the differences between these 2 VM’s can lead to bad tuning recommendations and performance problems.
Please feel free to post any comment or question on the JRockit VM.
Published at DZone with permission of Pierre - Hugues Charbonneau, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Wojciech Kudla replied on Thu, 2012/12/27 - 4:41am

Jrockit does not store classes in native heap. It does use Java heap for that purpose.

Pierre - Hugues... replied on Thu, 2012/12/27 - 10:57am

Thanks Wojciech  for your comments,

Actually by "classes" I meant the class metadata (e.g. static class representation) and this is indeed stored in the native memory space. This is why you will get error when using JRockit VM such as OutOfMemoryError: classblock allocation, 110787528 loaded, 84224K footprint, in check_alloc (src/jvm/model/classload/classalloc.c:215) when native memory is depleted; especially common for 32-bit VM. Monitoring the Java Heap alone will not give you the true picture of your memory footprint, including the presence of native memory leaks.

You can also monitor the native memory space from the JRockit VM using JRCMD tool. This will allow you to track the Java class meta data pool separately.

EX: 2 GB Java Heap space 

JRCMD <Java PID> print_memusage

Total mapped  2380976KB  (reserved=2096720KB)

-  Java heap  2097152KB  (reserved=1966080KB)

-  GC tables  139092KB

-  Thread stacks  9216KB  (#threads=18)

-  Compiled code  512KB  (used=315KB)

-  Internal  776KB

-  OS  25068KB

-  Other  105832KB

Java class data  2304KB  (malloced=2066KB #2525 in 458 classes)

- Native memory tracking  1024KB   (malloced=207KB #8)

Class instances/Java objects are obviously stored in the Java Heap itself.

If you run out of native memory when using a 32-bit VM or physical/virtual/swap memory, class loading operation of the JRockit will fail as per above OOM error (including new Thread creation).

Find below the explanation and source from the OpenJDK implementation, including the plan to merge HotSpot & JRockit (now targeted in Java 8). PermGen will be broken down & move to Java Heap (interned Strings and class statics) and native memory(class meta-data).

## Source (OpenJDK) 

“The proposed implementation will allocate class meta-data in native memory and move interned Strings and class statics to the Java heap. Hotspot will explicitly allocate and free the native memory for the class meta-data. Allocation of new class meta-data would be limited by the amount of available native memory rather than fixed by the value of -XX:MaxPermSize, whether the default or specified on the command line.”



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.