What is Java VisualVM?

01.14.2009

| 16370 views |

Java VisualVM, the new JDK tool since JDK 6 Update 7, provides a wide range of troubleshooting features for various kinds of Java applications. Whether you're new to this tool or already have some experience with it, the brand new screencast below should serve to give you a thorough introduction or answer any questions you might still have about it:

Should this tool do things it currently doesn't? Feel free to leave any thoughts for the Java VisualVM engineers here. Alternatively, have a look at the related site, https://visualvm.dev.java.net/, where you will also find info about mailing lists.

Originally posted here on Blip.tv.

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Geertjan Wielenga replied on Thu, 2009/01/15 - 11:53am

One cool addition would be... video capture (via JavaFX integration). Imagine how cool it would be if you could capture a video of the live data displayed in Java VisualVM and then send that video to whomever should end up fixing the problems identified by the tool? There'd be a button to "Start Capture" and to "Stop Capture", as well as, I guess "Preview" and "Send" and then you could send it to someone via e-mail.

Mike P(Okidoky) replied on Thu, 2009/01/15 - 3:04pm

Detecting memory leaks is a big deal. In order for that to work, you'd have to take a heap dump, perform an operation, take another heap dump, and then compare the two heap dumps.

Does VisualVM let you do that?

Jiri Sedlacek replied on Fri, 2009/01/16 - 6:42am in response to: Mike P(Okidoky)

Mike,

the HeapWalker in VisualVM cannot compare two heaps, that's a feature to be implemented. But note that it will only compare number of instances for each class. The heap dump doesn't contain the information required for comparing individual instances (which instances are in both dumps, newly allocated, gc-ed).

Currently you can use the profiler to take memory snapshots and compare them, this way you'll see which classes are leaking. Then you can take a heap dump and analyze which objects are preventing the leaking instances from being garbage-collected.

Mike P(Okidoky) replied on Fri, 2009/01/16 - 11:48am in response to: Jiri Sedlacek

It shouldn't be very hard to implement a comparison. It could simply offer to show the differences between two heap dumps. Internally, it could copy the data structures of the collected data from dump 1, and then take away everything found in dump 2. The left over, dump 3, can then be treated as if it's a fresh heap dump, same ui. I kind of don't see the point of having access to heap dumps at all, unless you can compare them. The way it's now is nice to look at, but I bet no developers ever use it.

Profiler. You mean a profiler inside VisualVM? I'm confused. A profiler attempts to collect performance data, correct? It too has a way a snapshotting the heap?

Jiri Sedlacek replied on Fri, 2009/01/16 - 12:25pm in response to: Mike P(Okidoky)

I think you should read some docs to learn how other developers use it - start for example with http://kirk.blog-city.com/more_on_memory_leaks.htm and http://blogs.sun.com/nbprofiler/entry/profiling_with_visualvm_part_1. The keywords are GC Root and Compare Memory Snapshots.

I agree that there's a lot to improve in the heapwalker, but many things can be done right now with the current tooling and appropriate knowledge. BTW, you may want to file a RFE for VisualVM for the features you're missing.

Michael Bien replied on Sat, 2009/01/17 - 2:31pm

visualvm is a very good tool but there are two features i really miss, both are a little bit related to each other:

1. the monitoring graphs display only the recent history (around 1hr AFAIR) this is often not enough for serverside monitoring. If its possible there shouldn't be a limit

2. Application snapshots should store monitored data (all graphs). There are currently only a namespace for all heap and threaddumps you took until the application dump was triggered if i understood them correctly.

the good news is that jconsole remembers the complete history of the memory graph. Thats why i used jconsole for memory monitoring and took every day a screenshot to compare memory comsumption and gc activity with different configurations. Would be great to have both issues impemented in a future release ;) i think they are already somewhere in the bugtracker.

(and a decent gclog viewer would be awesome)

Jiri Sedlacek replied on Sat, 2009/01/17 - 5:37pm in response to: Michael Bien

Hi Michael,

graphs cache is customizable in Options, you can change the default 1hr history and 1sec polling interval. Having unlimited history with some disk storage would definitely be nice, this is a good feature candidate for future releases.

Extending persistence to application snapshots is planned - currently all heap dumps, thread dumps and profiler snapshots are stored into a snapshot together with the Overview tab contents. Persisting the Monitor tab contents is planned for the near future, stay tuned.

Jiri

Michael Bien replied on Sat, 2009/01/17 - 5:49pm in response to: Jiri Sedlacek

perfect ;)

as anand replied on Tue, 2009/09/22 - 9:34am

HI, Can you please let me know how to compare two graphs of jconsole and find whether out of memory problem is resolved or not. how to measure the memory utilizations or compare them. regards a.s.