Friday, July 8, 2011

JVisualVM - Java's hidden monitor and profiling tool

There are a few different ways of profiling your Java application.  One is using the -prof switch when calling running a Java app.  This will output a profile file when the app is terminated.  Another is a third party app like Yourkit.  Yourkit is great, but you have to add a something to the commandline and after 30 days full free trial is its super expensive.

Finally in recent editions of the JDK there is jvisualvm.exe.  Make sure you have the JDK and not just the JRE.  locate the install directory and find the bin directory.  There you should find the executable.  Once you open it up you can go to tools and add some additional plugins.  On the left hand side you will see the available JVMs that are connected.  The good thing about this profiler/monitor is that you don't need to add anything to the commandline like you do with Yourkit.  In your kit you have to add something to connect to that yourkit agent.  Here it just connects and you can see all the JVMs running.  Each instance of Java should run in a new JVM so you can run and view many different programs at once.  It gives you a basic view of the memory and processor usage along details about calls to GC and the number of threads and classes being used.  Additionally you can run a profiler to which will sample the application and give details of either cpu or memory usage.  This is extremely useful in finding memory leaks or in my case optimizing your code.  I do a large amount of number crunching which tends to use a lot of memory and cpu, using jvisualvm I have reduced the amount of memory used and made the whole process more efficient.  There are other features that let you view information about classes.

I came across and a problem when running jvisualvm the other day.  The executable ran and but it did not detect my running application. I ran an old version of my application and found that it was detected.  In the end I have discovered that for some strange reason the java executable has to be running with code located on the same drive.  Its very strange but seems to be the only solution I am aware of.  If anyone else has seen this problem let me know, especially if you solved it in another way.  As usual drop me line if you have questions that I haven't answered in this post.
Happy optimizing.

No comments:

Post a Comment