JRockit vs HotSpot JVM Difference

Jrockit was developed by Appeal Virtual Machines and acquired by BEA Systems, and later on acquired by Oracle.

HotSpot is a Java Virtual Machine (JVM) currently hold by Oracle Corporation. 

JRockit is based on the HotSpot JVM by Sun Microsystems, and now Oracle. It has been developed in order to make HotSpot more reliable, and faster to used in server side environment. Jrockit has a slightly bit different heap organisation, garbage collector methods, and optimisations. More information about GC for HotSpot can be found here.

Although JRockit is supposed to have more optimised functions, it is not the rule. Some applications might run faster under HotSpot, and some can be tuned more for JRockit. You don't know it until you try it :)

Additional information:

http://en.wikipedia.org/wiki/JRockit
http://stackoverflow.com/questions/8068717/jrockit-jvm-versus-hotspot-jvm
http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

http://weblogicserveradministration.blogspot.com/2010/11/differences-between-bea-jrockit-sdk-and.html

Garbage Collectors - HotSpot

TL;DR

Types of Garbage Collectors in HotSpot:

• Serial
• Parallel
• Concurrent (CMS)

Young Generation Collectors:

1. -XX:+UseSerialGC
2. -XX:+UseParallelGC (Use parallel for Young, Serial for Old)
3. -XX:+UseParNewGC

Old Generation Collectors:

1. -XX:+UseParallelOldGC (Parallel Young and Old)
2. -XX:+UseConcMarkSweepGC –XX:-UseParNewGC (Concurrent Mark Sweep with Serial Young)
3. -XX:+UseConcMarkSweepGC –XX:+UseParNewG (Concurrent Mark Sweep + Parallel Young)

Additional note:

-XX:+DisableExplicitGC - prevent calls to System.gc()

Details:

Serial collector:

-XX:+UseSerialGC

Serial Collector - runs in single thread. No communication overhead between the threads. Used for mini data sets (<100MB). This collector is quick but suited for single CPU machines.

Parallel collector:

-XX:+UseParallelGC

and (optionally) enable parallel compaction with

-XX:+UseParallelOldGC 

-XX:+UseParNewGC

This type of collector is similar to the serial collector, but runs with multiple threads and does the minor collection in these threads. Be default:

N garbage collector threads = N CPUs on the host.

We can take the control over the number of threads by using the following option:

-XX:ParallelGCThreads=[number of threads]

Concurrent collector:

-XX:+UseConcMarkSweepGC 

One thread is used during initial mark and remark phase. For the concurrent marking and sweeping, CMS thread runs along the application threads. Used when the short pauses and response time are crucial.


In this collector parallel version of the young generation collector is used. For the Old/ Tenured generation, serial collector is used.


Concurrent low pause collector:

-Xincgc ™ or -XX:+UseConcMarkSweepGC

This collector is used to collect Old Generation and is done concurrently with the running application, however application is still paused for short amounts of time during the collection.. A parallel version of the young generation copying collector is used with the concurrent collector. 

Incremental low pause collector:

-XX:+UseTrainGC

This is currently not under the development, and has not changed since the J2SE Platform version 1.4.2

Note:


ParallelGC partially implies the -XX:+UseConcMarkSweepGC and should not (this doesn't mean you can't use it ;) ) be used in the same cmd line.

Garbage Collection (GC)

Garbage Collection is integral part of the JVM (Java Virtual Machine) and it is used to reclaim memory occupied by the unused objects.

When the application runs, it creates objects. Once the object is created it occupies some memory. When the object is not used/ referenced it can be considered as unused and will remain in the memory until the garbage collector claims the memory occupied by this object.

Objects at first are created and put in the Young Generation space. After some time can be moved (Partial/ Minor Garbage Collection) into the Old Generation space. Once the Young and Old Generation is FULL, Full Garbage Collection is run. 

This operation might impact the flow of the application, as it might take a very long time to complete. During this operation application becomes unresponsive.

To avoid this, we can tune the JVM Heap/ other settings. Different JVMs have different GC policy algorithms which will be discussed in the next posts.

Examples:

If we add the following option to the command line for the JVM:

-verbose:gc

we will get the information about the heap and result of the garbage collection for each collection.

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

In this scenario we can see two minor GC and one Full/ Major GC.

• First numbers stand for the size of live objects before and after the GC.
• Numbers in parentheses represent memory space usable for java objects (perm/ survivor spaces not included).
• Secs stands for the amount of time in seconds that was taken to perform the action

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

Here the second numbers represent the heap usage reduction (196016K -> 133633K(261184K)



If we want to get even more details on the GC results we can add the following options:

-XX:+PrintGCDetails

If we add:

-XX:+PrintGCTimeStamps

we will get additional information regarding timestamps when the GC occurred  Based on such results we can see how often GC occurs.