VisualVM : Visual Tool for Viewing Detailed Information about Java Applications

Java VisualVM is a tool that provides a visual interface for viewing detailed information about Java technology-based applications (Java applications) while they are running on a Java Virtual Machine (JVM). Java VisualVM organizes JVM data that is retrieved by the Java Development Kit (JDK) tools and presents the information in a way that enables you to quickly view data on multiple Java applications. You can view data on local applications and applications that are running on remote hosts. You can also capture data about the JVM software and save the data to your local system, and view the data later or share the data with others.

It is a free opensource visual tool integrating several commandline JDK tools and lightweight performance and memory profiling capabilities. The tool is available under the GNU GPLv2 with Classpath Exception license. Some of the features in VisualVM include :

1. Display local and remote Java applications.
2. Display application configuration and runtime environment.
3. Monitor application memory consumption and runtime behavior.
4. Monitor application threads.
5. Profile application performance or analyze memory allocation via profiler.
6. Take and display thread dumps.
7. Take and browse heap dumps.
8. Analyze core dumps.
9. Analyze applications offline.
10. Extendable via plugin architecture.
11. and there is much more. You can read the documentation here. Already there are a number of plugins -
12. MBeans Browser.
13. JConsole Plugins Container.
14. VisualVM Extensions.
15. Visual GC Plugin.
16. GlassFish Plugin.
17. BTrace Plugin.
18. The Thread Dump Analyzer (TDA)

You can get mor details on these plugins from the VisualVM plugin page. Most of these are available from the VisualVM Update Center.

The out-of-the-box features it perfectly fits all the requirements of application developers, system administrators, quality engineers and - last but not least - application users submitting bug reports containing all the necessary information. “After eight months of frantic development since VisualVM Preview 1 was released, I’m happy to announce the general availability of JDK 6 Update 7 Java VisualVM and VisualVM 1.0,” said Luis-Miguel Alventosa, a Sun senior software engineer, in a blog. Offered as part of Java Platform, Standard Edition (SE) Update 7, Java VisualVM provides a visual diagnostic tool for development and production environments. It includes such technologies as jvmstat, which provides lightweight performance and configuration instrumentation to the HotSpot JVM, as well as Java Management Extensions and the NetBeans profiler.

In any event, Java VisualVM is a new GUI-based tool for troubleshooting Java applications. It incorporates technology from multiple projects, including among others, jstack, JMX, and the NetBeans profiling tools, in order to provide one easy-to-use visual diagnostic tool for both development and production environments.

The NetBeans IDE has had for many years some very powerful tools for profiling Java applications and now some of those tools are available outside of the IDE in Java VisualVM. The user interface for those profiling tools, however, is a bit different in Java Visual VM. This is not surprising, since Java VisualVM does not have access to the source code for the application when doing profiling.

Let's see what the entire buzz is all about.

(1) You can find VisualVM under the bin directory of your JDK6u7 installation. Just double click the exe and its there the VisualVM.


(2) The main window of VisualVM opens when you launch the application. By default, the Applications window is displayed in the left pane of the main window. The Applications window enables you to quickly see the Java applications running on local and remote JVMs. The Applications window is the primary entry point for viewing further details about a particular application. Right-clicking an application node opens the popup menu where you can choose to open the main application tab or take thread or heap dumps.

If you have used the Netbeans platform, you can easily recognize that VisualVM is also built upon the Netbeans Platform.

Now that you have VisualVM running you can do several things like

1. Create and visually view heap Dumps
2. Profile memory usage
3. Profile CPU Usage
4. Profile Threads

In the past you had to use one or more commercial tools to get the above tasks done. But with VisualVM you have one integrated tool that can do all the above.

How to Analyse Memory Leaks in Java Application using VisualVM

Memory Leak is a decease and OutOfMemoryError (OOM) is the symptom for that. However all OOM doesn’t necessarily implies Memory Leak. OOM can happen due to the generation of large number of local variables – particularly with large number of concurrent requests (in the case of server applications). On the other hand all memory leaks not necessarily manifest into OOM – especially in the case of desktop applications or client applications (those are not run for long without restart). Memory leaks also can be in heap, perm space, or in native memory.

Following section talks only about memory leak in heap. How to verify that memory leak is the reason for OOM in your case is also out of scope (probably will discuss some other day). How to attack memory leaks in perm space is also out of scope (again another day’s work). I have absolutely no clue about debugging memory leak in native memory (Google search with error messages).

Memory Leak in Heap

(1) Run the application with latest available JDK (JDK 1.6 as of now). New versions of java contain lot of improvements in debugging tools. Run the application with different operations repeatedly to identify the operation that causes memory leak. We don’t need to wait until OOM to identify memory leak. Monitoring the heap using any tool can identify memory leak. Run the application until it reaches a steady state. Monitor the heap size over a period of time. If the ‘heap size after full GC’ (full GC remember) increases each time, that implies a memory leak. We can use visualVM also for this purpose.

Now we have identified the operation that causes memory leak – means if we invoke this operation repeatedly we will get OOM. (What if we could not identify the operation that causes memory leak?). Now onwards we assume that this operation runs continuously.

(2) Install VisualVM. You need to install VisualVM separately – unlike many other java debugging tools this one doesn’t come along with JDK [ Thanks to Jiri Sedlacek's comment! VisualVM is part of JDK from jdk1.6 update 7 onwards ]. Just unzip the file to any convenient location.

(3) Run visualVM - you can run visualvm by executing ‘visualvm.exe in the bin directory. (You should have jdk 1.6 in path?)

(4) Connect to the application – all the java processes running in the machine are listed in the left side pane (name of the main class shall be listed). You can double click the one you are interested. Right side there are four tabs – monitor and profiler are the ones we are interested in.

(5) Go to the profiler tab. Check the settings checkbox it will display different options. Go to the memory settings tab. Check the ‘record allocations stack traces’. Uncheck the ‘settings’ checkbox; that will close the settings options display (all changes are automatically saved).

(6) Now click on the ‘memory’ button – this will start memory profiling. Wait for few seconds – it will take a while. A tabular display of different classes, its instance count, total byte size etc are displayed.

(7) Wait for a while to allow the application to be in stead state.

(8) Take a snapshot of the objects by clicking the button on top of the tabular view (see below screen shot). A snapshot is generated and labeled in the left side pane as well as opened in the right side pane.

(9) Wait for some more time to allow some memory leak. Take one more snapshot as explained in the previous step. Now we have two snapshots displayed at the left side pane (also opened in the right side pane).

(10) Select both of these snapshots (in the left side pane, by using ‘ctrl’ button we can select multiple items), right click and select ‘compare’. A comparison tab shall be opened in the right side pane. That tab will display items that have been increased during the interval of first and second snapshot. The top item is the suspect of memory leak.

(11) Go to the profiler tab again. Select the identified item in the previous step. Right click and select ‘Take snapshot and show allocation stack traces’. One more snapshot is generated. This time in the right side pane, an allocation stack traces sub tab also visible. It lists different places where this particular item is instantiated and it’s percentage of total count.

(12) Wait for some more time to have more memory leak. Take one more snapshot with allocation stack traces.

(13) Take a heap dump of the application. We can take heap dump by right clicking the application in the left side pane and select ‘heap dump’. Heap dump is also displayed in the left side pane as well as opened in the right side pane.

(14) Now come back to the tow snapshots with stack traces. Compare these two snapshots with allocation stack traces. Identify the methods where there is large difference in contribution to total count. These are the places where leaked objects are instantiated.

(15) Go to the heap dump tab in the right side pane. Go to the Classes view. Double click on the item identified in step 10. Instances of that class are displayed. Choose one instance which you feel could one of the leaked objects (just intuition). Look at the right bottom pane. Expand the view. You will find the objects that is holding referenced to the leaked objects. This is the reason for memory leak.

(16) From the items identified in step 10, and clue we got from step 13 and 14 we could resolve the memory leak issues. We get the object which leaked, the place of instantiation, and the objects that hold reference to it.

VisualVM allows you to do much more than traditional monitoring and profiling :

1. You can take a snap shot of the thread status and heap status and save them for analyzing offline.
2. You can monitor multiple applications both local and remote from a single VisualVM instance. You can also take simultaneous thread dumps of multiple applications for analyzing distributed dead locks.
3. No need for complex configuration. Traditional memory profilers either require you to run your applications in a special, modified JVM or start your applications with the profiler agent. But with VisualVM, you start your java applications normally and VisualVM automatically lists the Java applications running on your local machine.
4. VisualVM is extensible. Yes we love plugins, and since VisualVM is built on the NetBeans Platform, its architecture is modular and easy to extend with plugins. There are several plugins already available for VisualVM like:- MBeans Browser, JConsole Plugins Container, VisualVM Extensions, Visual GC Plugin, GlassFish Plugin, BTrace Plugin, TDA Plugin.

With the release of the 3rd milestone, you can try out the APIs and create your own plugins. When you go to the download page for VisualVM, you'll see a link for the VisualVM binary as well as a Milestone 3 API Docs link. That gives you access to the Javadoc, as well as an overview of the entrypoints to VisualVM. However, note that the API is still in progress and cannot be considered stable yet.

[ Download Java VisualVM ]