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.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}