Over a million developers have joined DZone.

Java Heap Space – JRockit VM

DZone's Guide to

Java Heap Space – JRockit VM

Free Resource

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

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.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.


Published at DZone with permission of Pierre - Hugues Charbonneau, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}