Profiling Java App using Visual VM

Profiling Java App using Visual VM
Balaji Chopparapu

















Learning is the only kind of treasure that multiplies when it is given around to others. When not done so, it starts shrinking and dies out.
-Anonymous
 
1. Memory leaks in java
2. Circular reference.
3. Creating a memory leak
4. True Leak
5. Profiler

 
1. Memory leaks in java
Most people think Java cannot leak memory, but actually that’s not true. Java, unlike languages such as C or Javascript, can have two kinds of memory leaks:

* True leaks – unreferenced, unrecoverable segments of memory
* Soft leaks – memory that could be garbage collected, but is “accidentally” referenced

The first kind of memory leak, the true leak, is common to C. It’s trivially easy to write a C program which leaks memory like a sieve by simple putting a call to malloc(…) inside a tight loop. This creates unbounded amounts of heap memory and eventually runs out of space. Additionally, the memory is lost if you don’t save a pointer to it. However, the same program in Java will not run out of memory


The above program should lead to memory problem. (i.e) the program should terminated with Out of memory but it will not happen because of automatic garbage collection in java
Let’s Analyze the program


In the infinite while loop. The objects of class MemoryLeakDemo are created using new operator and not destroyed. Once the scope of the block is lost the memory allocated to object is garbage collected by JVM. This makes the program not to run out of memory and there is not memory leak in it.
Program out put


Memory graph by running the program for 5 min.


In the above memory graph the amount of heap size allotted is 5MB and the memory consumption by the program varied between 1MB to 2MB.
2. Circular Reference:
The object has the self reference to it. In the example the MemoryLeakDemo has self reference to it.
Even though the objects has circular reference the garbage collector is intelligent enough to find out unused objects and remove them from memory



3. Creating a Memory Leak:
The easiest way to create a memory leak is to have objects with long life cycle has reference to objects with shorter life cycle.
Let’s enhance the program to create a memory leak

In the above code the Arrylist object “longLivedObject” has reference to “shortLivedObject” that's reason though the “shortLivedObject”s lost the scope they are not garbage collected.

Let’s analyze their memory consumption by running the program for 5 min

In the above figure you can observe there is considerable increase in heap size from 1MB to 29MB. This is because the shortLivedObjects are not garbage collected. This happened due to longLivedObjects has reference to shortLivedObjects.
If the program is allowed to run for while it may lead to out of the memory error once the max heap sixe 68MB is consumed.


4. True Leak
Though, there is a way to create true memory leaks in java, and that is with a poor implementation of the finalize method.

Throwing any kind of Exception or Error from finalize() also prevents the garbage collector from reclaiming the memory
5. Profiler
Profile the java application using Visual VM
Visual VM is a profiling tool that comes with JDK1.6. This allows us to identify the memory consumed, stack call trace ..etc of a java application.
In our example lets us take a small Calculator application and verify the time taken by each method.

The above Calculator application performs few basic mathematical operations like add, sub, div and mul. Let’s analyze the time take by each operation using Visual VM
Start Visual VM:
C:\Program Files\Java\jdk1.6.0_14\bin\jvisualvm.exe

Under the Local node you can see currently two applications are running in this Virtual Machine. They are Visual VM and Netbeans 6.7
Double click on the leaf node (application) to see the details of the java process (Netbeans 6.7).

The above screen shows the overview of the Net Beans 6.7 process.
Let run the Calculator.java in debug mode by setting the break points. This helps us to monitor the application in VisaulVM. If we didn't set the break point s and run the application, we will not get the sufficient time to monitor the app in Visual VM.

Run the application in debug mode and observe an instance in Visual VM.

Click on the Calculator process and Select the profile tab. Here you can see set of packages that are profiled. Select settings and provide the package you want to profile, for example org.bytesforall.demo.** . This profiles all the subclass and packages in under the package org.bytesforall.demo
After providing the necessary package clicks on CPU to profile the class Calculator.java, than release the break point and observe the call trace.

The above stack trace shows the methods that are called and their execution time.