/ Java Heap Space – JRockit VM ~ Java EE Support Patterns


Java Heap Space – JRockit VM

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
Java Heap
-Xmx (maximum Heap space)

-Xms (minimum Heap size)

- verbose GC
- 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.


Hi PH ,

Which is better performer Oracle JDK or JRockit ?
Is it good to have JRockit . ?


Hi Kiran,

In my experience, both JVM’s are good but it depends of your targeted OS. I have seen very good results when using JRockit on Windows but better HotSpot behavior & stability when used on Solaris OS. I have seen more instability (JVM crash / hang) problems with older version of JRockit given it does more native optimization with increased native memory utilization; causing trouble for some low physical RAM capacity environment like Windows 32-bit with 2 GB or 3 GB process limit.

Please keep in mind that Oracle is merging JRockit & HotSpot in one single JVM (merging best features of both) so this debate won’t be necessary in the future.


As P-H said Oracle is in process to merge best of both world and release the code as well (not sure whether its complete or just few modules) under OpenJDK. so far hotspot is our go to JVM in Linux as well as Windows Boxes.to get most of your JVM you also need to familiar with JVM parameters, specially tuning part. This list of JVM parameters is good starter.

Hi Pierre,

Can you please elaborate on this point:
** Process size limit of 2 GB, 3 GB or 4 GB depending of your OS **
i.e., explain a little more on the process memory size limits for different OS?


Hi Ani,

Some OS versions like older Windows 2003 32-bit by default does not allow you to create a process size bigger than 2 GB by default. Other OS such as Solaris process size is 4 GB. I will get back on this subject with a seperate post showing you the different max process size per OS.


Hi Pierre, if JRockit takes up native heap for all class metadata like Hotspot does in PermGen, is there anything like how much memory is picked up by JRockit for these purpose? Any command line argument like we have in Hotspot for manipulating permgen space?

Hi Zim,

This is a very good question. For JRockit VM, similar to IBM JVM implementation, there is no parameter that allows you to control the metadata memory footprint. The limit will depend if you are using a 32-bit JVM or 64-bit.

- For 32-bit on OS such as Linux, Solaris or AIX, the metadata limit will depend how much memory is left to the 4 GB process size limit.
- For 64-bit JVM, it is essentially limited by the amount of virtually memory available from the OS.


Post a Comment