jrockit Archive

Understanding JRockit Runtime Analyzer (JRA) Recordings

JRA recording (JRockit Runtime Analyzer) is one of the best feature that JRockit Mision Control gives us. As the name suggests, it records all the data from current heap usage to garbage collection. All the possible details will be recorded.

To take JRA recording of the server, in the JVM Options add:
-Xmanagement:autodiscovery=true,authenticate=false,ssl=false,port=<port number to use>
default port is 7091

When the server is started, go to the directory D:\BEA_Home\jrockit_Home\bin and start jrmc.exe. You will see the jrmc console running.

Now in the Discovered -> Local tab, you will see that the server is connected to the JRMC tool, right click on the server on which you want to take a JRA recording on and click on “Start JRA Recording”.

In the next screen, in the drop down list check JRA recording normal. Give the location of the directory where you need to save the recording and enter the minutes or seconds of how long do you need the recording.

When you check the Show Advanced Options, it will ask you if you want thread dumps, latency data, heap statistics and CPU statistics. Enable them as per your preference. Enabling the options will give you extra information about the server.

The next screen shows the processing and the details of recording that is being taken.

When the recording is done, it will open the recording taken. Else open the recording by clicking new on the menu bar.

Below is the detailed explanation of the recording:
1– General information (1st screen) : It will give all information about memory allocations for the server, JVM arguments, thread count, exceptions and errors. Most importantly it will give you the complete version of the JDK used and the operating system.

2– Click on Methods. This screen gives you all the information of which methods are using the maximum memory. If there is an application deployed on the server, it will also show the methods being called in the application and the percentage of memory consumed by them. Click on the individual package to get the whole list of methods on the right side.

3– Click on GC General. This will give you all the information about the garbage collection. Like how many times has the gc happened, how many young generation gc and old generation gc, gc pauses etc. It also tells you the reason for gc as seen in the screen shot. This explains that the gc happened to get New Native TLA space.

When you click on the gc strategy changes, on the left side it gives information about which algorithm is used for garbage collection.

4– Click on GCs.  The gc chart shows you the complete graph of garbage collection from beginning to end. On the gc chart, click on any point and it will give you the information about type of gc, gc pause, reason for gc etc. The section garbage collection gives you details about young and old objects GCed.

To get more information about the gc, cpu usage etc, click on the drop down list in the gc charts.

Garbage collection section shows the summary of young and old generation gc.

5– Click on Heap. It will show you the commited heap, large objects size, fragmented heap etc at the end of the recording.

6– Go to Objects. It will give you a list of most common objects created and the percentage of heap occupied by each of them. It gives a data of how was the memory situation in the beginning of the recording and at the end of recording. You can see the clear comparison.

7– Latency Recording : If you select Latency recording in advanced options before taking the JRA recording, latency data will be recorded. This is helpful in monitoring performance of the server and check what is hampering the performance.

Latency Log is the list of events that have caused the latencies.

Latency Graph : This shows the threads involved when the latency was recorded.

Latency Traces : These are the stack traces which were involved in causing the latencies. This is helpful in knowing the root cause of performance issues.

8– Click on the Optimization tab. This will give you the data of the number of methods optimized before and after sampling. It will give the complete list of methods. This also shows the number of JIT compilations (byte code to machine language conversion) and also the time taken to do so.

9– Go to the tab Locks: This shows the information about which java locks was the application mostly blocked on. This helps in knowing where to tune your application code for better performance of the server.

If you have any doubts or need any clarifications, please let us know. We will be glad to help you.

Best Regards.

Comparison Between Sun JDK And Oracle JRockit

As we all know, JVM is responsible in converting the java byte code into machine code (which the machine understands)
Sun jdk and Oracle JRockit do the same thing using different mechanism.

Sun JDK uses interpreter (Interpreter and JIT in previous releases) — In this mechanism, the byte code is read and the translated into machine language, but these results are not saved in the memory. So every time even if the same method is run again and again, the JVM has to translate the code into machine language. This means machine code will not be reusable as it is not saved anywhere in the memory.

Oracle JRockit uses only JIT compiler (Just In Time) — JIT mechanism means, once a method is run, the byte code is translated to machine language and this is saved in the memory. This means if the method is run again, there is no need for translation and the machine code is reused.

Because of the interpreter mechanism used by sun jdk, the start up time for the server is faster because it does not have to save the machine code in memory. Once the translation is done for a method, it moves to the other one. Where as oracle JRockit saves the code, which is why  start up takes longer. For the same reason, oracle JRockit uses more memory than sun jdk.

In the long run, JRockit gives a slightly better performance as compared to sun jdk.

Oracle JRockit optimizes the code. It identifies the HOT SPOTS which means the methods that are being run more often. These methods are then queued up for optimization. This code is then optimized which improves performance. Many issues are seen becuase of the code optimization mechanism because it is a complex procedure. Optimization can be disabled.

JIT is also used by Sun JDK, but that was in the earlier versions. The Java Hotspot VM removes the need for a JIT compiler in most cases.

Memory spaces in jdks:

Sun JDK has the following memory spaces: Eden space, survivior space, tenured generation and permanent generation. The objects move from one space to another according to its age and survival from garbage collection.

JRockit has 2 spaces, young generation and old generation, it uses the same mechanism of garbage collection. There is nothing called as permanent generation in JRockit.

Memory and other JVM tunings:

JRockit gives advanced JVM tunings. From the release R26 and above, JRockit takes care of few tunings by itself. For example if there is an outofmemory occuring on the native TLA in previous releases due to insufficient TLA size which is 2k by default, in later releases the JRockit tunes these settings as per the requirement of the application. This has to be done and taken care of by the user in case of sun jdk. But then it is always better to be in a safer side it is recommended to have the tunings done by self.

JVM Crashes:

When JRockit crashes, a JRockit dump is produced which basically has the reason for the crash. JRockit uses native libraries by default. This can be disabled by disabling the NativeIO from the admin console. The most common reason for the JRockit crash is the conflict between native libraries. For example, the jdbc type 2 drivers which use native libs. It is recommended to use type 4 pure java drivers when using oracle JRockit. Another reason for the crash can be code optimization because of its complexity. The stack trace in the JRockit dump will show the exact cause. When the JVm crashes, it is important to test it again by disabling code optimization and check if the issue still persists.

A sun jdk crash produces hs_err_pid file which has the root cause of the crash. There can be several reasons for sun jdk crash are due to bugs in them (defects in the code of the jdk). These issues need to be reported to the sun team.

Tools for performance tracking:

Sun jdk that comes bundled with weblogic server gives tools like JConsole which can be used for performance tracking and monitoring the memory in use of the JVM. This tool is very much necessary so that each and every detail about the memory being used by the application, cpu usage, memory leaks can be identified.

Oracle JRockit has a much more advanced tool JRMC (JRockit mission Control) which gives advanced tracking features. JRA recordings can be taken which gives each detail about the JVM arguements, garbage collection details, methods using the maximum memory etc. The memory leak detector tool in JRMC is also one important and very helpful tool. These make it easy for the user and administrators to maintain a record and identify the issues with the application and the JVM.

If you have any queries related to both the jdks, please feel free to get back to us.