An Oracle blog about NetBeans Profiler

Profiling With VisualVM, Part 2

This article describes advanced profiling features of the VisualVM tool which give the user more control over the profiling session and collected data. You may also want to read the Profiling With VisualVM, Part 1 article describing the basic profiling features of VisualVM.

By default, the Profiler UI in VisualVM doesn't display any settings, the initial configuration ensures that even an unexperienced user will get some useful results with zero configuration by just clicking the CPU or Memory button. However, an advanced user still has the possibility to fine-tune the settings and fully utilize the power of the NetBeans profiler engine.

To display the settings area, Settings checkbox has to be selected in the topright corner of Profiler tab. The settings area consists of two tabs, CPU settings and Memory settings, containing controls for each profiling mode.

Note that the settings can only be changed when the profiling session is not in progress, during profiling the settings area is disabled.

There's also a Restore Defaults button available at the bottom of the area which restores the initial configuration. This is useful when the values were customized incorrectly and no profiling data are being collected.

Profiling Performance

For performance profiling there are two important settings available: profiling roots and instrumentation filter. In general, profiling roots define when the profiler should start collecting the data whereas instrumentation filter defines packages/classes from which the data should/shouldn't be collected.

Start profiling from classes textbox defines the profiling roots. If all the methods were instrumented, the profiling overhead would be enormous and profiling would eventually become unusable. That's why the NetBeans profiler introduces a notion of Root Methods - a way to profile just the code of interest while the rest of the application runs at full speed.

A typical usecase is for example profiling performance of an action invoked by a button click - if the appropriate actionPerformed() method is set as a root method, the profiler starts instrumenting and profiling the application once the actionPerformed() method is invoked and only profiles the methods called from the actionPerformed(). This way the profiling overhead is very small and only relevant profiling results are collected which greatly improves their readability.

Whereas in NetBeans profiler selecting a root method is very natural because of its tight integration with the editor, in VisualVM this might be a bit tricky and not exactly user friendly. That's why VisualVM defines profiling roots by classes - all methods defined in these classes and their innerclasses become root methods. In the similar way, package names can be used as profiling roots. That's how the default profiling roots are defined: <main_class_package>.** which means that all methods from <main_class_package> and subpackages are profiled.

The default settings work in most cases, but for large applications like application servers it might be useful to tweak the profiling roots to point to a concrete code of interest. For example, when profiling a web application it's much better to set the servlet's package or classname as a profiling root instead of profiling the whole server.

The format for entering the profiling roots in VisualVM is following:

  • org.mypackage.** defines all methods in org.mypackage and all subpackages as root methods
  • org.mypackage.* defines all methods in org.mypackage as root methods
  • org.mypackage.MyClass defines all methods in org.mypackage.MyClass and its innerclasses as root methods
  • empty textbox means that all methods executed in the application will be profiled

Multiple profiling roots (separated by a space and/or comma and/or newline) can be defined for a single profiling session.

Note that it doesn't make sense to define org.mypackage.MyClass.* or org.mypackage.MyClass.** as profiling roots since the tool always selects all methods of the class and its innerclasses as profiling roots.

Profile only classes / Do not profile classes textbox defines the instrumentation filter. This is exactly the same option as Quick Filter in the NetBeans profiler. It either defines the only packages/classes to be profiled or packages/classes not to be profiled. For example, if only an application's code should be profiled without any outgoing calls to other frameworks or JDK code, this option should be set to Profile only classes, <application_package>.*. If all the code except JDK classes from java and javax packages should be profiled, this option should be set to Do not profile classes, java.*, javax.*. The default instrumentation filter is Do not profile classes, java.*, javax.*, sun.*, sunw.*, com.sun.* (+ com.apple.*, apple.awt.* on Mac OS X) which filters out all the JDK code.

The format for entering instrumentation filter is following:

  • org.mypackage.* selects all classes from org.mypackage and subpackages to be profiled or to be excluded
  • org.mypackage. selects all classes from org.mypackage to be profiled or to be excluded
  • empty textbox selects all classes of the application to be profiled

Multiple filter values (separated by a space and/or comma and/or newline) can be defined for a single profiling session.

Profiling Memory

For memory profiling there are three important settings available: profiling scope, density of tracked objects and recording allocations stack traces.

The profiling scope is defined by one of two choices: for the Profile object allocations option only object allocations are monitored. This is useful when evaluating how many objects are allocated by the application. For checking and identifying memory leaks the second choice is more useful - Profile object allocations and GC. In this mode the allocated objects are monitored during the whole lifecycle, from their allocation till garbage collection. This allows to easily identify live objects currently allocated on the heap at certain point. Also, in this mode the Surviving Generations metrics is available (see this article for more information). By default, Profile object allocations and GC option is selected.

The Track every Nth object allocations option allows to define density of tracked objects. In most applications it isn't necessary to monitor each single instance, the overall allocations behavior is the same when tracking just each Nth object. The advantage of this approach is lower profiling overhead. To get exact number of allocated or live objects, this option has to be set to 1. By default, each 10th object is tracked.

The third control is the Record allocations stack traces checkbox. When selected, a stack trace is taken for each monitored object when allocated. This allows to identify the concrete method (and its call tree) which has allocated the object. By default the collecting of allocation stack traces is disabled to lower the profiling overhead.

Note that by default some columns of memory results are hidden. You can display more metrics using the top-right corner button in Profiling results or memory snapshot tables.

Comparison With The NetBeans Profiler

This section compares profiling settings available in the NetBeans profiler and VisualVM. For the settings which cannot be customized in VisualVM the predefined value is listed.

CPU profiling settings:

Settings NetBeans profiler VisualVM
Profiling roots packages/classes/methods/project methods packages/classes
Instrumentation filter predefined sets/user defined/project code user defined
Profiling points enabled/disabled N/A
Profiling technique instrumentation only/instrumentation & sampled time instrumentation only
Exclude Thread.sleep() & Object.wait() time on/off always on
Profile underlying framework startup on/off always off
Profiling technique instrumentation only/instrumentation & sampled time instrumentation only
Profile new Threads/Runnables on/off on/off
Profiled threads limit 1 to unlimited always 32
Thread CPU timer (Solaris only) on/off always off
Instrumentation scheme total/eager/lazy always lazy
Instrument Method.invoke() on/off always on
Instrument getters/setter on/off always off
Instrument empty methods on/off always off

Memory profiling settings:

Settings NetBeans profiler VisualVM
Profiling scope object allocations / object allocations & GC object allocations / object allocations & GC
Density of tracked objects track every to every Nth object track every to every Nth object
Allocations stack traces on/off on/off
Profiling points enabled/disabled N/A
Limit stack traces depth 1 frame to unlimited depth always unlimited depth
Run GC when getting results on/off always on

Note that you can easily determine the used profiling settings in both NetBeans profiler and VisualVM by selecting the Info tab of the CPU or memory snapshot.

Further Reading

For more information see the VisualVM Documentation, especially the Profiling Applications section.

You may also find the NetBeans Profiler 5.5 documentation useful, especially the Instrumenting a Root Method, CPU Profiling settings or Memory Profiling Settings sections.

Join the discussion

Comments ( 9 )
  • Sunil Tuesday, November 4, 2008

    can we profile runnig applicaton using VisualVM?

    i want to profile application running on solaris from windows.

    please suggest.

  • Jiri Sedlacek Tuesday, November 4, 2008

    VisualVM only allows profiling locally running applications, remote profiling is not supported. Use NetBeans profiler for profiling remote applications.

  • Sunil Tuesday, November 4, 2008

    Thanks Jiri,

    how we can profile application already running on solaris from window.i dont want to start the application.it will be up always and i should be connected to that server anytime i wanted.I tried to do using direct attachement mode of netbean profiler but unbale to do so if you can guide more, that will be great help

  • Jiri Sedlacek Tuesday, November 4, 2008

    You cannot profile an already running remote application using the NB profiler - the dynamic attach mode used for profiling already running applications is available only locally (JDK limitation).

    If you need to profile the application on Solaris, then use local VisualVM / NetBeans profiler (dynamic attach) installation OR remote NetBeans profiler (direct attach) - application restart is required.

    Check these links for more information about profiling with VisualVM / NetBeans profiler:

    - https://visualvm.dev.java.net/profiler.html

    - http://profiler.netbeans.org/docs/help/5.5/attach.html

  • Sam Friday, October 9, 2009

    How can I profile the CFC objects in Coldfusion? I was able to do it in JRockit, but seems VisualVM is not displaying any of those in the memory profiler.


  • Jiri Sedlacek Friday, October 9, 2009

    Sam: If you can't see the objects in VisualVM please file a bug report at https://visualvm.dev.java.net/issues/enter_bug.cgi?issue_type=DEFECT and describe your steps. This is the best way to either get some advice or have a potential bug fixed for the next VisualVM version.

    BTW have you tried the Sampler plugin for VisualVM 1.2 Test Build available at http://tinyurl.com/visualvm12tb?

  • Marc van Dongen Sunday, February 6, 2011


    Thanks for this information. I've been using CPU profiling within netbeans and it works fine there. However, when I try to profile using jvisualvm from the command line it just doesn't show any information about main own methods. The text in the "Start profiling from classes:" text is empty.

    What am I doing wrong?

    Thanks in advance for your help.


    Marc van Dongen

  • guest Monday, September 19, 2011

    hi the memory sampling button is disabled when i am trying to profile a remote linux server.

    What can be the reason???

    i am finding it very difficult.

  • Anatoliy Monday, December 19, 2016

    Links to article part 1 is not valid now.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.