Friday Apr 30, 2010

Problems Adding Remote Hosts in VisualVM on Linux/Solaris

Some problems have been identified in VisualVM when running on Linux or Solaris using OpenJDK or JDK 7. Due to a JDK bug in GTK LaF implementation it's not possible to open the Host customizer in VisualVM 1.2 and newer. This affects the 'Add Remote Host' and 'Host Properties' actions which throw a java.lang.NullPointerException and don't allow to edit and/or add hosts. Details are available in the VisualVM Troubleshooting Guide.

There's an easy workaround to this problem, the VisualVM can be configured to use a different look'n'feel: visualvm --laf Nimbus or visualvm --laf Metal. The LaF to be used can be configured permanently in visualvm/etc/visualvm.conf configuration file. Another possibility is to run the VisualVM using Sun JDK 6.

The problem is now resolved on VisualVM side in development builds and will be available in the next release.

Monday Aug 24, 2009

Five VisualVM Myths Demystified

VisualVM has been released more than one year ago and since then several myths appeared around the tool without any real basis. Continue reading this article to uncover the five most frequent errors:

VisualVM is not (just) a Java profiler

Many users call the tool the "VisualVM Java profiler" and compare it with the commercial Java profilers. VisualVM is a Java monitoring and troubleshooting tool - it detects and recognizes running applications, browses their MBeans, takes thread and heap dumps, shows VM configuration and metrics and saves these information into application snapshots. It also provides basic profiling capabilities, but that's just one of the features. If you need a full-featured mature Java profiler for your daily development, check out the NetBeans profiler.

VisualVM doesn't see all Java applications

The users expect VisualVM to see at least all the locally running Java applications. Not seeing a Windows service Java process in the Applications tree is a quite often complaint. The truth is that VisualVM only lists the applications started by the same user who's running the tool. This is how the jvmstat technology used by VisualVM works, the same applications can be listed by the 'jps' command. The applications not discovered by VisualVM can be added manually using a JMX connection.

VisualVM doesn't require Sun JDK

In many articles around the Web there's a note that VisualVM doesn't work with other than the Sun JDK, namely that it cannot be used on Mac. Not correct, VisualVM itself runs fine on Sun JDK 6+, Open JDK 6+, Apple JDK 6 and HP-UX PA-RISC JDK 6. Monitored applications can run virtually any 1.4+ JDK, the tool has been tested to work with Sun JDK, Open JDK, Apple JDK, JRockit JDK, IBM JDK, HP-UX PA-RISC JDK, SAP JDK and Diablo JDK. Based on the JDK version and vendor various amount of information and features is available.

NetBeans profiler isn't VisualVM integration into the NetBeans IDE

The NetBeans profiler is sometimes incorrectly mentioned to be the VisualVM integrated into the NetBeans IDE. This statement is kind of inside out, VisualVM reuses some of the NetBeans profiler's features: profiling engine, HeapWalker, threads monitor, UI components etc. NetBeans profiler has been introduced in 2004, VisualVM in 2007. The VisualVM - IDE integration is available for Eclipse and IDEA.

VisualVM-JConsole plugin is not JConsole integrated into VisualVM

"I've installed the JConsole plugin and it doesn't show any tab!" Why? Because the plugin is a container for the JConsole plugins which runs them inside VisualVM. It's not the JConsole tool itself. Typically you don't want to install the plugin at all unless you've got a custom JConsole plugin which you need to use in VisualVM.

There's one more thing which is often misunderstood about the tool - its name. It's not "Visual VM" nor "VVM", also "JVisualVM" or "jVVM" is incorrect. The only correct name of the tool is VisualVM if it's the standalone release from and Java VisualVM when it's the JDK tool located in the bin directory.

Thursday Jul 23, 2009

Two Tricks On Using VisualVM

This blog describes two useful tricks on using the VisualVM tool. They won't find a performance bottleneck or memory leak for you but definitely will make using the tool even easier:o)

Doubleclick to invoke default action in the Applications tree!

Each node in the Applications tree can define some actions which are displayed in it's right-click popup menu. There may be one action in the menu which is displayed in bold which means it's a default action. Default action is typically the most useful action for the node and can be invoked immediately by doubleclicking the node or pressing Enter for the selected node. What's this good for? You can easily open an application or Local host using their node, add a new host using the Remote node, add a core dump using the VM Coredumps node or add an application snapshot using the Snapshots node.

Hold down the CTRL key when taking a snapshot to not open it!

By default if you take some kind of snapshot in VisualVM it's immediately opened. Sometimes this is not what you want, maybe you just want to take a heap dump and save it for later investigation. How to suppress the automatic opening of the snapshot? By holding the CTRL key down when invoking the Take Snapshot action. This works for taking the thread dumps, heap dumps, profiler snapshots and application snapshots across the VisualVM UI.

Thursday Jan 22, 2009

Monitoring Java Processes Running As a Windows Service

This post describes how Java processes running as a Windows service can be monitored and/or profiled using VisualVM. By default, when you start VisualVM only Java applications started by the same user are listed in the Applications tree. But sometimes you may need to monitor or profile for example Tomcat running as a Windows service. There are several ways to do it using VisualVM:

Using JMX connection

pros: easy to setup
cons: profiling not available

JMX connection can be used to monitor any local/remote Java application in VisualVM incl. the locally or remotely running Java services. All you need to do is to start the service to be monitored with some extra arguments defining JMX connection parameters. Details on how to setup a JMX-enabled application are available here. Once started, you can connect to the application using the Add JMX Connection action. Drawback of this solution is that you cannot profile applications defined by JMX connection, only the monitoring features are available.

Running VisualVM as a service

pros: allows profiling services
cons: not available on Windows Vista

Since only Java processes running under the same user as VisualVM can be profiled, the only way to profile Windows service (which is by default running under the System account) is to start the VisualVM itself as a Windows service. Note that this approach doesn't work on Windows Vista due to security restrictions which by default prevent the services to display any UI. If you have appropriate permissions (ideally perform as Administrator) follow these steps:

  1. Get the instsrv.exe and srvany.exe tools if you don't have them already, they are for example part of the Windows Server 2003 Resource Kit Tools.
  2. Create a Windows service to launch the VisualVM using this command:
       c:\\wrk\\instsrv.exe VisualVM c:\\wrk\\srvany.exe
    This will create a new srvany service (a wrapper service to start any executable) called VisualVM. General instructions on creating new Windows services are available here.

  3. Using a registry editor (regedit.exe, regedt32.exe) create a new Key called Parameters in HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\VisualVM. Then inside the Parameters key create a new String value (REG_SZ) called Application containing a full path to visualvm.exe. This will instruct the srvany service to start VisualVM.

  4. Make sure the service is configured to run under Local System account with 'Allow service to interact with desktop' option enabled. Also, it's a good idea to set the service Start up type to Manual.

Once you have performed the steps, you can simply start the VisualVM service which will launch the tool in context of System account. After confirming the VisualVM license dialog you should see all the running Java services in Applications tree and all the features incl. profiling should be available.

Running jstatd as a service

pros: automatic discovery of remote services
cons: profiling not available, works only remotely

Instead of running the VisualVM itself as a service, you can run the jstatd daemon as a service. This will make all running Java services visible to the jvmstat technology used by VisualVM to automatically discover Java applications. Note that you cannot use this approach for monitoring locally running Java services, it only works remotely. In general, the steps are exactly the same as for running VisualVM itself as a service:

  1. Get the instsrv.exe and srvany.exe tools if you don't have them already, they are for example part of the Windows Server 2003 Resource Kit Tools.
  2. Create a Windows service to launch the jstatd.exe using this command:
       c:\\wrk\\instsrv.exe jstatd c:\\wrk\\srvany.exe
    This will create a new srvany service (a wrapper service to start any executable) called jstatd. General instructions on creating new Windows services are available here.

  3. Using a registry editor (regedit.exe, regedt32.exe) create a new Key called Parameters in HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\jstatd. Then inside the Parameters key create a new String value (REG_SZ) called Application containing a full path to jstatd.exe and security parameters. This will instruct the srvany service to start the jstatd daemon. See the jstatd man page for details on setting up the daemon.

  4. Make sure the service is configured to run under Local System account. Note that the 'Allow service to interact with desktop' option doesn't need to be enabled as jstatd.exe is a command-line tool without any UI. Also, it's a good idea to set the service Start up type to Manual.

Once you have performed the steps, you can simply start the jstatd service and the host as a new host in the remote VisualVM. All the Java services should then be displayed under the host node in Applications tree. Details on monitoring remote applications are available here. Note that profiling won't be available for these applications.

Monday Aug 18, 2008

Hg Repository and Continuous Build

Like all other NetBeans development teams, Profiler team has to use mercurial (hg) from February. Since the traffic and number of broken builds in main NetBeans repository is alarming, we asked our release engineering to set up separate NetBeans Profiler mercurial repository called profiler-main and continuous build. We update profiler-main once a day from main-golden. Main-golden is updated from main only if it can be built successfully and the basic set of tests passed. This way we can work on relatively stable build of NetBeans. When fixing bugs we first push changeset to profiler-main and corresponding bug is closed as FIXED in IssueZilla, than the fix is propagated to main and from main finally to main-golden. Corresponding issue is automatically updated with information about public build. If you don't want to wait for fix to be propagated to main-golden you can download NetBeans with fix from our continuous build.

Tuesday Jan 22, 2008

How to see long JVM arguments in VisualVM

If JVM arguments string is longer than 1024 bytes, you will see that JVM arguments are truncated in VisualVM. This is generally not a big problem, but some applications like application servers can have very long list. If you want to see whole list, you can fortunately increase 1024 string length limit with PerfMaxStringConstLength VM option. One can add -XX:PerfMaxStringConstLength=new_limit or better add PerfMaxStringConstLength=new_limit line to ~/.hotspotrc file.

See the results for GlassFish application server without and with PerfMaxStringConstLength added to .hotspotrc


Wednesday Sep 12, 2007

Adding custom libraries to JMeter in NB

Lately, we had an issue filed about adding the mail.jar to the JMeter plugin distribution (see here to see the details).

This might seem as a valid request until you realize that the JAR in the question is an optional one and there might be many more optional JARs required for running particular JMeter tests there surely must be a better way to that than including ever more libraries in the distribution.

And there is - you just need to copy the library to ${jmetermodule}/lib directory. Depending on whether you choose to install the JMeter module in the shared directories or not the ${jmetermodule} resolves as one of the following

  1. ${nbuserdir}/modules/jmeter - for the standard installation
  2. ${nbinstall}/extra/modules/jmeter - for the installation into shared directories


Monday Sep 03, 2007

Profiler Actions in IDE Toolbar

In Profiler 6.0 Milestone 10 the toolbar changed a bit - profiler toolbar has been merged with Build toolbar and Profile Main Project & Attach Profiler actions have been replaced by one dropdown icon with Profile Main Project as default action and Attach Profiler action available from the dropdown menu:

If you like the original toolbar with separate Profile Main Project & Attach Profiler actions you can easily change it to meet your needs. Right-click the toolbar in empty area to open a popup menu and click Customize..., it will open Customize Toolbars dialog. Find Profile category there and drag'n'drop Attach Profiler action to the toolbar next to the dropdown icon:

The same way Profile Main Project action can be added. Finally you can remove the dropdown icon by drag'n'dropping it from the toolbar to the Customize Toolbars dialog:

You can also create separate toolbar for profiler actions by clicking New Toolbar... button in the dialog and dragging profiling actions there.

Thursday Jul 19, 2007

How To Obtain Heap Dump With JDK 5.0

There are various ways how to obtain heap dump with JDK 5.0.

  • You can request that a heap dump will be created when an OutOfMemoryError is first thrown by using -XX:+HeapDumpOnOutOfMemoryError HotSpot VM option. Note that NetBeans Profiler automagically uses this option if you run your application under profiler. This means that heap dump is done and opened in HeapWalker if you encounter an OutOfMemoryError while doing profiling or monitoring.
  • You can use HPROF: Heap and CPU Profiling Agent. A complete dump of the current live objects in the heap can be obtained with:
    java -agentlib:hprof=heap=dump,format=b -jar application
    This will automatically dump heap when java application is terminated. You can also force heap dump by sending QUIT signal to java process with kill -QUIT pid command.
    This option causes the greatest amount of memory to be used because it stores details on every object allocated, it can also impact the application performance due to the data gathering.
  • jmap can also create heap dump directly from running java application with command:
    jmap -heap:format=b pid
    however jmap -heap:format=b in JDK 5.0 is more suited for recovering a heap dump from a core dump file rather than taking the heap dump of a running java application. jmap can observe the heap in an inconsistent state and hence the dump file is not always useful. It is also slow because it is reading the target process though /proc. And finally it is available only on Solaris, Mac OS X and Linux. So jmap should be avoided for taking heap dumps of running java applications on JDK 5.0. Note that for JDK 6 this has been fixed and jmap can produce consistent heap dump of running JDK 6 applications and is also available on Windows.

It looks like there is no good way to obtain a heap dump at runtime with JDK 5.0. Both jmap and hprof native agent library is not suitable to get heap dump, but fortunately NetBeans Profiler has Dump Heap action which can be invoked either during profiling session from Profile menu or during memory profiling as a secondary action of Take Snapshot button in Profiler Control Panel. It will create consistent heap dump at runtime even on JDK 5.0. The only condition is to use latest JDK 5.0 update 12.

Thursday Apr 12, 2007

Where Have My JMeter Scripts Gone?

Are you puzzled why all your JMeter scripts you had created for load testing your application mysteriously got unreachable from the Profiler?

Recently we have received following question:
"In Milestone 8 how do I get the 'Load Generator Script' checkbox at the bottom of the SPT dialog to be enabled?"

The answer is short - go and download the 'Profiler Bridge' module from the 'Development Update Center'. It is located in the 'Load Generators' category. Yeah, it's that easy :)

Wednesday Jan 24, 2007

Tweaking Profiler Timeouts

In general the Profiler consists of two independent parts: Profiler tool and Profiler agent. During profiling these two parts communicate together and are able to notify each other about important lifecycle events - Profiler tool sends a "Profiling stopped" command to the agent which stops profiled application or the agent informs the tool about profiled application shutdown.

In case the communication between tool and started agent fails for some reason, the agent might block the profiled application and prevent it to startup completely or shutdown correctly. For this reason a connection timeout mechanism is implemented which automatically finishes the agent and profiled application if the connection to the tool isn't established in time. For Direct Attach you may control the timeout manually as described in Understanding Profiler Agent Parameters post. For Profile Project action where the agent is started automatically the timeout is 10 seconds by default.

Another failure may happen during agent startup or if the agent isn't started at all. This is typical for profiling J2EE applications due to profiled server startup failure. When a J2EE application is being profiled using Profile Project action, the Profiler tool asks appropriate server plugin to start target server in profiling mode and then tries to connect to the agent. If a problem occurs and the agent doesn't (fully) start, the tool timeouts waiting for the agent after 20 seconds by default.

Default values for both timeouts are set to allow smooth profiling startup when everything works correctly and on the other side to timeout trying to start profiling session if anything fails. But sometimes you may need to profile some application on some machine where the default timeout is not enough - either the application does some extra processing before starting the Profiler agent and/or the system is simply slow. In that case there's a possibility to tweak default timeout values by setting the following properties:

  • profiler.agent.connect.timeout - [seconds], default=10, since Profiler 6.0 Milestone 6 - timeout after which the already started agent not able to connect to Profiler tool stops itself and the profiled application.
  • profiler.agent.startup.timeout - [milliseconds], default=20000, since Profiler 5.0 - timeout after which the Profiler tool not able to connect to the agent gives up profiling J2EE application using Profile Project action.

To set (one of) these properties, start the NetBeans IDE with appropriate option: netbeans -J-D<>. For example setting the agent connection timeout to 20 seconds can be done by starting the IDE using netbeans -J-Dprofiler.agent.connect.timeout=20.

Monday Nov 27, 2006

Profile Javac!

Two weeks ago Sun Microsystems announced opensourcing key Java implementations including javac, the Java programming language compiler. You can get the javac source code also from with a detailed tutorial to getting, building, and running the javac sources in NetBeans IDE.

Since the javac sources are available as NetBeans project inside the IDE, you can easily build and run the compiler as well as investigate how things work inside. For this the Profiler can be also useful showing you the stack traces and other information about compiler's runtime. Just follow these five simple steps to check out how easy is now to profile javac.

  1. Download and install NetBeans IDE 5.5 and NetBeans Profiler 5.5.
  2. Follow these instructions to download javac source code and open it as a project in the IDE.
  3. Create sample J2SE project in the IDE using New Project wizard: category Samples/General, project Anagram Game. For the following instructions the project is expected to be located in C:\\AnagramGame.
  4. Edit the javac buildscript build.xml: append target profile for example below target build-bin.javac.
  5. Set javac project as the Main project and invoke the Profile Main Project action. Choose Java platform for profiling (most likely the Default one) and select the profiling task you want to use. After clicking the Run button the Profiler asks you to select the ant target for profiling - choose profile in the combo and click OK.

That's all - now you are profiling compilation of Anagram Game by the javac!

Note: The above scenario is for Windows and Anagram Game project. If you want to profile compilation of other project/application on other operating system, you need to modify (some of) following target properties:

  • app.dir: root directory of profiled project/application
  • app.mainclassfile: relative path to mainclass java file of profiled project/application
  • app.srcdir: relative path to profiled project/application source root
  • app.builddir: relative path to profiled project/application compiled classes root

Tuesday Nov 07, 2006

Understanding Profiler Agent Parameters

Anytime the profiled application is started for Profiler direct attach, the -agentpath argument of java command is used to load the Profiler agent into JVM. For Profile Project action this happens automatically and you don't have to care about it. But when you are using the Attach Profiler action, you have to start the profiled application manually and provide correct -agentpath argument. Synopsis of the argument is:



  • path_to_agent_library is full path to Profiler agent binary, on Windows %NB_INSTALL%\\​profiler1\\​lib\\​deployed\\​jdk15\\​windows\\​profilerinterface.dll
  • path_to_profiler_lib_dir is full path to Profiler lib directory, on Windows %NB_INSTALL%\\​profiler1\\​lib
  • comm_port_number is Profiler agent communication port, must meet the value set in Profiler Options, default is 5140
  • timeout_in_secs is optional timeout value in seconds which defines the time for which the agent waits for Profiler GUI connection; if elapsed, the agent breaks profiled application startup and stops its JVM. If not provided, default value 0 is used which means no timeout

The timeout_in_secs option is useful when you use some kind of automated connection of Profiler GUI to the agent or just when you are not sure that the Profiler GUI will be able to connect to the agent. The timeout ensures that profiled application won't stay blocked when connection fails. The Profiler itself uses timeout for Profile Project action for J2SE projects, its value is 10 seconds.

Note that you don't have to construct the -agentpath argument manually, the Attach Wizard will generate it for you - you can just copy-paste it to the console.

Wednesday Oct 18, 2006

Install NetBeans And Profiler Silently

In 6.0 devbuilds/milestones of NetBeans and Profiler there's a support for a silent installation. This means that you can set install options in a config file and launch the installer without UI and any interaction, working just with the config file.

Here's a simple howto for Windows. First you need to download the installer, let's call it installer.exe for reference. Then invoke following command from command line: installer.exe -options-template installscript.txt. This will create a template for the config file. Edit it to meet your needs and then just invoke the installer again: installer.exe -silent -options installscript.txt. The installation now runs!

Tip: on Windows the automatic installation is asynchronous, invoking installer.exe returns immediately and the installation runs in the background. To start it in a blocking way, use start /w installer.exe <arguments...>.

Here are sample scripts for silent NetBeans and Profiler installation:


    -W license.selection=1
    -P installLocation="C:\\Program Files\\NetBeans"
    -W jdkselect.jdkHome="C:\\Program Files\\Java\\jdk1.5.0"


    -W license.selection=1
    -W beanNbSelectionPanel.nbHome="C:\\Program Files\\NetBeans"

Wednesday Oct 04, 2006

Space in Path on Windows

Sometimes you may experience problems when using the Profiler installed in path which contains spaces. Whereas for using Profile Project action everything works fine, for Attach Profiler where you have to start profiled application with special "-agentpath" argument problems may occur. For default NetBeans installation directory on Windows the argument typically looks like this:

-agentpath:"C:\\​Program Files\\​netbeans-5.0\\​profiler1\\​lib\\​deployed\\​jdk15\\​windows\\​profilerinterface.dll=\\​"C:\\​Program Files\\​netbeans-5.0\\​profiler1\\​lib\\​"",5140

However, some applications/servers parse this argument from command line incorrectly and pass it to the Profiler agent in bad format. Typically you will find something like "Profiler Agent: Options: >\\C:\\Program<" in profiled application's console in that case and profiled application fails to start.

There is a simple workaround to fix this problem: 8.3 DOS path format should be used, it doesn't contain spaces in path. Then all quotes and escape backslashes need to be removed. Profiler argument in this format looks like this:


Whereas for "C:\\Program Files" the short form should always be "C:\\PROGRA~1", for other directories you should ask the OS for correct path. You can do it in Command Prompt (cmd.exe) using dir /X command. In general getting 8.3 paths is not as trivial as it may seems, the best way is to call GetShortPathName function of Windows API.

And - of course - another simple workaround is to move the NetBeans directory somewhere on path without spaces.


A blog by NetBeans Profiler & VisualVM developers.


« June 2016