X

An Oracle blog about NetBeans Profiler

Recent Posts

Features

Profiling Live Process With NetBeans Profiler 8.1

This article is a modification of the Getting Started With NetBeans Profiler 8.1 guide describing how to connect and profile an already running Java process. See profiler documentation for details on configuring and running the profiler. The profiler is able to connect to any local process running on Java 6+ and started by the same user who runs the NetBeans IDE, without any additional configuration of that process. When running on Microsoft Windows, the profiled process must not be a Windows Service and must run the same Java architecture as the NetBeans IDE (32bit→32bit, 64bit→64bit). 1. Get The Profiler: Download the NetBeans IDE 8.1 distribution of your choice (Java SE technology is a requirement to get the profiler) and install or unzip it to your system. Create a sample Java application Anagram Game using File | New Project... | Samples | Java. 2. Start Sample Application: Select the AnagramGame project node in Projects window and invoke the Run Project (AnagramGame) action either in the Run menu or the IDE toolbar. The action can also be invoked using the F6 shortcut. The project is started and Anagrams window opens. That's the running process to be profiled in the following steps. 3. Open Profiler Window: Select the AnagramGame project node in Projects window and create a profiling session for this project by invoking the Attach to Project (AnagramGame) action either in the main IDE menu or the IDE toolbar. Profiler window representing new profiling session opens in the editor area. When profiling a process without the corresponding project, the Attach to External Process action needs to be used. 4. Configure Profiling Session: Click the Configure Session button in the Profiler window toolbar and select the profiler mode of your choice (for example Methods). The Profiler window displays a hint for each profiling mode to help you select the right one. Once a mode is selected, the Profiler window starts displaying its actions in toolbar and results view in the rest of the area. See Profiling Methods docs for details on profiling application performance. 5. Select The Process: Click the Attach button dropdown arrow and select the Setup Attach to Project... item to open the Attach Settings dialog. This dialog shows a list of all locally running Java processes available for profiling. The list of processes can be refreshed at any time using the Reload processes button at the bottom of the dialog. Selecting a process instructs the profiler to connect to this process each time the Attach button in Profiler window toolbar is pressed. In case the Always connect to <process> option is selected, the list shows just the processes with the selected class name. In case there's exactly one such process available for profiling, the profiler will attach to it automatically even if its process ID differs from the selected one. See Profiling Local Running Process docs for details on selecting the process to be profiled. 6. Start Collecting Data: Start the profiling session by clicking the Attach button in the Profiler window toolbar. This action connects the profiler to the running process and starts profiling it. Based on the profiler mode selected in step 6. you'll see the profiling data being collected. In case the process to be profiled isn't set up correctly, the Attach Settings dialog described in the previous step is displayed and you have to select the right process for profiling. 7. Switch Profiler Mode: Modify the profiling mode on the fly while the profiled application is running by clicking the Attach button dropdown arrow and selecting a different mode from its context menu (for example Objects). The mode is changed immediately after selecting it and the Profiler window starts displaying new data. See Profiling Objects docs for details on profiling application memory usage. 8. Finish Profiling Session: Finish the profiling session by clicking the Finish profiler session button in the Profiler window toolbar. This action detaches the profiler from the profiled process without terminating it and stops getting the results. You can also terminate the profiled process by closing its window to stop the profiling session. In this case you'll be given a chance to take a snapshot of the profiling data collected so far (not possible once the session has terminated). 9. Restore Profiling Session: Close the Profiler window and/or restart the NetBeans IDE. Create a new profiling session for the Anagram Game project or External Process and note that all the settings have been persisted for the project/process from the previous session, including the attach settings. If the previously selected process to attach is still running, it will be automatically reused for the new profiling session. Congratulations, you've just learned how to profile an already running Java process with the new NetBeans profiler!

This article is a modification of the Getting Started With NetBeans Profiler 8.1 guide describing how to connect and profile an already running Java process. See profiler documentation for details on...

Features

Getting Started With NetBeans Profiler 8.1

This article provides a step by step guide to create, configure and start the first profiling session for a project with the new NetBeans profiler 8.1. See profiler documentation for details on configuring and running the profiler. 1. Get The Profiler: Download the NetBeans IDE 8.1 distribution of your choice (Java SE technology is a requirement to get the profiler) and install or unzip it to your system. Create a sample Java application Anagram Game using File | New Project... | Samples | Java. 2. Open Profiler Window: Select the AnagramGame project node in Projects window and create a profiling session for this project by invoking the Profile Project (AnagramGame) action either in the main IDE menu or the IDE toolbar. The action can also be invoked using the Ctrl+F2 shortcut. Profiler window representing new profiling session opens in the editor area. 3. Configure Profiling Session: Click the Configure Session button in the Profiler window toolbar and select the profiler mode of your choice (for example Methods). The Profiler window displays a hint for each profiling mode to help you select the right one. Once a mode is selected, the Profiler window starts displaying its actions in toolbar and results view in the rest of the area. See Profiling Methods docs for details on profiling application performance. 4. Start Collecting Data: Start the profiling session by clicking the Profile button in the Profiler window toolbar. This action starts the project the same way as using the Run action and automatically configures the profiler to collect data from its process. Based on the profiler mode selected in the previous step you'll see the profiling data being collected. 5. Switch Profiler Mode: Modify the profiling mode on the fly while the profiled application is running by clicking the Profile button dropdown arrow and selecting a different mode from its context menu (for example Objects). The mode is changed immediately after selecting it and the Profiler window starts displaying new data. See Profiling Objects docs for details on profiling application memory usage. 6. Finish Profiling Session: Finish the profiling session by clicking the Finish profiler session button in the Profiler window toolbar. This action terminates the profiled project and stops getting the results. You can also terminate the profiled process by closing its window to stop the profiling session. In this case you'll be given a chance to take a snapshot of the profiling data collected so far (not possible once the session has terminated). 7. Restore Profiling Session: Close the Profiler window and/or restart the NetBeans IDE. Create a new profiling session for the Anagram Game project and note that all the settings have been persisted for the project from the previous session. Congratulations, you've just learned the essentials of profiling with the new NetBeans profiler!

This article provides a step by step guide to create, configure and start the first profiling session for a project with the new NetBeans profiler 8.1. See profiler documentation for details on...

News

NetBeans Profiler 8.1 Released

NetBeans IDE 8.1 include a reworked Java profiler which provides simplified user interface, improved profiling views and optimized engine. The profiler now uses a single window which contains controls to configure and control the profiling session and display the collected results. The session is configured by selecting a profiling mode using the Profile dropdown menu and started by clicking the Profile button without providing any special settings. If needed, the settings can be tweaked using the Settings pane displayed on demand above the profiling results. Methods profiler introduces live forward and reverse call trees in addition to the live hot spots view. The data may be filtered or aggregated by selected threads and can be displayed as absolute or incremental values. Objects profiler displays live allocation call trees if configured and is able to profile instances of just the selected classes, lowering the profiling overhead and amount of collected data. Telemetry profiler introduces monitoring CPU utilization and GC overhead, Threads profiler adds filtering capabilities to the timeline view. The profiler newly supports taking thread dumps from the profiled application. Attaching to already running processes has been significantly improved both on the UI and engine side. The profiler now displays all processes available for attach in a table and remembers the selected process between profiling and/or IDE sessions. Visit http://profiler.netbeans.org to see detailed list of news and changes, read profiler documentation and download NetBeans IDE 8.1 including the profiler.

NetBeans IDE 8.1 include a reworked Java profiler which provides simplified user interface, improved profiling views and optimized engine. The profiler now uses a single window which contains controls...

News

VisualVM 1.3 Released

The new version of the VisualVM tool is now available athttps://visualvm.dev.java.net.VisualVM 1.3 introduces several new features and improvements, extends the API for plugins and fixes many bugs.Details of the changes can be found in the Release Notes.Let's look at the most interesting new features in more detail: Sampler In The Core Tool The sampling profiler that was originally provided as a plugin has now been integrated into the core tool.Sampler provides a lightweight and safe way to determine performance bottlenecks and memory problems and adds minimal overheadto the target application. It can be used for local and remote applications running on JVMs from different vendors and is designed to be used in production environments.Once a problem is identified, it can be further analyzed in detail using the instrumenting Profiler with appropriate settings (profiling roots, instrumentation filter).Profiler is available for local applications running on an Oracle/Sun-compatible JDK and is mostlyintended as a profiling tool for Java developers. Sampler And Profiler Presets All the Sampler and Profiler settings can now be saved into presets and reused for further application/VisualVM sessions.This makes it much easier for developers to analyze and improve applications using the iterative profile-fix-restart approach.Moreover, a preset can be selected automatically for an application based on its main class or display name. Remote Heap Dumps In previous releases, the VisualVM was only able to take heap dumps of applications that were running locally.The only way to dump the heap of a remote application was by using the MBeans plugin and invoking the appropriate MBean operation (com.sun.management.HotSpotDiagnostic | Operations | dumpHeap).Starting with VisualVM 1.3, you can now use the Heap Dump actions and buttons in the tool to take a heap dump of applications that are running remotely.When invoked, a dialog is displayed that enables you to specify the full path on the remote system where you want to dump the heap.After the heap dump is created, you need to manually copy the file to your local machine and use the Load action to open and analyze the file using VisualVM. Monitoring Remote Hosts In every release of VisualVM it is possible to open the Local system node in the Applications view and seethe machine setup (OS, architecture, number of processors etc.), actual CPU load (not available for Windows OS) and physical & swap memory usage.VisualVM 1.3 enables you to obtain this information for remote hosts as well if the host has at least one JMX-enabled application defined in VisualVM.The data is obtained using the application's JMX connection.If the "proxy" application finishes, the live data will freeze and will be updated again when another JMX-enabled application becomes available on that host. Sorting Hosts, Applications, Coredumps And Snapshots By default, all nodes are sorted by the insertion time. This means that the last discovered application is added to the end of the list of running applications.In VisualVM 1.3 you can newly sort applications also according to their display name or process ID, which simplifies monitoring systems that are running many Java applications.The other nodes can now be sorted either by the insertion time or by display name. Tracer Framework And Probes Tracer is a new framework and GUI for monitoring and analyzing Java applications.Using various types of probes, Tracer gathers metrics from an application and displays the data in a timeline.This gives a quick overview of what is happening in various parts of the application and allows you to easily determine the relations between the metrics.The values are displayed both graphically and in a table and can be exported to common formats for further processing with external tools.VisualVM 1.3 comes with several sets of Tracer probes that are distributed as plugins: Monitor Probes, JVM Probes,Jvmstat Probes, Swing Probes, JavaFX probes and DTrace Probes. Threads Inspector Plugin The Threads Inspector integrates with the Threads tab and allows you to analyze the stack trace(s) of one or more selected threads directly withoutrequiring you to take and open full thread dumps.This is extremely useful when you need to quickly analyze various threading problems. Recognizing Alternative JVM Languages Some developers use VisualVM as a monitoring and profiling tool for alternative JVM languages that do not have dedicated tooling.VisualVM now recognizes the Clojure, Groovy, JRuby, Jython and Scala runtimes, enabling these developers to easily find the appropriate processes. Built On NetBeans Platform 6.9 VisualVM 1.3 uses the most recent NetBeans Platform and profiler release to ensure the best performance and greatest stability.The HeapWalker now displays local variables in the Threads section of the Summary | Overview view, providing a better context for thestate of the heap at the time the heap dump is created. VisualVM 1.3 is available for download at https://visualvm.dev.java.net. You can send your comments to the VisualVM developers by using the feedback mailing list. The API documentation can be found here.

The new version of the VisualVM tool is now available athttps://visualvm.dev.java.net. VisualVM 1.3 introduces several new features and improvements, extends the API for plugins and fixes many bugs.De...

Tips & Tricks

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 profilerMany 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 applicationsThe 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 JDKIn 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 IDEThe 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 https://visualvm.dev.java.net and Java VisualVM when it's the JDK tool located in the bin directory.

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: Vi...

Tips & Tricks

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.

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...

News

Java VisualVM Blogging Contest

/\* l1 \*/.l1{margin:10px 10px 0 10px;color:#000 !important}td .l1{margin:0}.l1v0,.l1v1{height:80px}.l1{background:url("http://www.sun.com/im/bg_white_to_grey.gif") repeat-x left top #fff}.l1 div.cornerBR{width:100%;background:url("http://www.sun.com/im/generic_br.gif") no-repeat bottom right;padding:0}.l1 a.morelink{font-weight:bold;white-space:nowrap}.l1 a.title{font-weight:bold;font-size:14px}.l1 div.copy{padding-top:4px}.l1 div.plft{background:url("http://www.sun.com/im/ar_lg_orange.gif") no-repeat top left;padding-bottom:0}.l1 .l1v0{color:#000}.l1 a:visited,.l1 a:link{color:#3E6B8A}.l1head{font-size:18px;font-weight:bold;margin-bottom:3px}.l1 .hotbutton{margin:0}.l1v1 .l1top{padding-top:4px}.l1v1 .l1lft{margin-left:240px;padding-right:100px}Java VisualVM Blogging Contest has been announced and started at http://java.sun.com/community/javavisualvm. If you enter the contest and blog about either the opensource VisualVM tool or Java VisualVM tool available in your JDK/bin folder you can win up to USD $500:Try Java VisualVM for a Chance to Win USD $500!Java VisualVM is a free tool to monitor, profile, and control Java technology-based applications. Try it and blog about it for a chance to win USD $500. » Get Started NowThe blogging contest starts on April 23rd, 2009 and ends on June 24th, 2009. You can enter the contest using the Submit link on the Blogging Contest page. See more information about the contest in Blogging Contest FAQ, official contest rules are available here.All the information you need to get started with VisualVM is available in the VisualVM Documentation and Resources, you can also check the Java VisualVM documentation. Useful tips on using the tool are mentioned on NetBeans Profiler (this) Blog, great docs about extending the tool can be found on Geertjan's Blog.Searching for some inspiration? You can check what the others already wrote about VisualVM. Happy blogging and good luck!

Java VisualVM Blogging Contest has been announced and started at http://java.sun.com/community/javavisualvm. If you enter the contest and blog about either the opensource VisualVM tool or...

Features

Visual GC Plugin 2.0 for VisualVM

The recently released VisualVM 1.1.1 introduced an updated Visual GC tool integration into VisualVM. From today the Visual GC Plugin 2.0 is also available for all other VisualVM and Java VisualVM releases via the Plugin Center. Visual GC is an experimental Visual Garbage Collection Monitoring Tool - a graphical tool for monitoring the HotSpot Garbage Collector, Compiler, and class loader. The tool was originally developed as demonstration software for JavaOne 2001 where it was used in a presentation to help describe how various tunable parameters affect the operations of the HotSpot generational garbage collector. In 2004 it was presented in technical session Using jvmstat and visualgc to Solve Memory Management Problems. Detailed information on using the Visual GC tool can be found on the Visual GC page. The latest standalone Visual GC tool can be downloaded here. Using the Visual GC plugin for VisualVM has several advantages over the standalone tool: No command-line launcher. The standalone tool has to be launched from a command-line with at least one argument specifying the PID of the Java process to be monitored. When using the VisualVM plugin, the Visual GC GUI is displayed in a separate subtab for each application. Remote monitoring without any special setup. When the jstatd daemon is already running on a remote server to enable the VisualVM to discover running remote Java applications, no special setup is required for Visual GC to monitor these applications. More user-friendly UI. The plugin changes the default Visual GC appearance to fit into VisualVM UI and provide better user experience. The most significant change is using white background instead of the default black. Changing the background color also required to change the graphs colors. The Application Information section has been removed - the information is already available in Overview subtab of each application. The plugin also sets default font for the labels, fixes several layout problems and allows to configure the refresh rate during runtime. Note that all these customizations can be switched off by starting VisualVM with a special argument -J-Dcom.sun.tools.visualvm.modules.visualgc.originalUI=true.    To install the Visual GC plugin for VisualVM, use Tools | Plugins in VisualVM menu bar and select the 'Available Plugins' tab. Alternatively, if previous version of the plugin is already installed, the updated plugin will be displayed in the Updates tab. You may need to click the 'Reload Catalog' button to refresh the available plugins if the older plugin version (1.1.1) is cached. When installed, the Visual GC subtab is added for each Java application. The graphs are available for all applications running Sun JDK 1.4.2+ with jvmstat available - this means that both local and remote applications can be monitored without any limitations (jstatd daemon must be running on remote hosts). The Histogram view may or may not be displayed by default depending on the application configuration - when the monitored VM uses Parallel Scavenge collection (using Server VM or setting -XX:+UseParallelGC or -XX:+AggressiveHeap), Histogram view is hidden by default. The refresh rate of Visual GC graphs is customizable during runtime, it can be changed using the Refresh Rate dropdown. The value is specified in milliseconds and the default value is Auto which means using the global refresh rate defined in Tools | Options | Polling - Monitored Data.

The recently released VisualVM 1.1.1 introduced an updated Visual GC tool integration into VisualVM. From today the Visual GC Plugin 2.0 is also available for all other VisualVM and Java VisualVM...

News

VisualVM 1.1.1 Released

VisualVM 1.1.1 tool has been released at https://visualvm.dev.java.net. This version delivers several important bugfixes and improves memory monitoring capabilities.    The most significant news are two plugins available on VisualVM 1.1.1 Plugin Center: Memory Sampler plugin: this plugin periodically polls the monitored application and lists classes, instances and live bytes allocated on Heap and PermGen. This is almost the same information as provided by live memory results of the built-in profiler but without any instrumentation and available for multiple applications at the same time. An advantage over the built-in profiler is the possibility to display delta values between the samples. Note that this plugin only works with local Java applications running Sun JDK 6 or 7. Improved Visual GC plugin: the Visual GC tool integration into VisualVM has been improved, the graphs are now displayed in a subtab for each monitored application. It works for both local and remote applications where jvmstat is available (jstatd must be running on remote hosts). Note that this plugin works only with Sun JDK 1.4.2 and newer. The most important bugfixes are: Issue 233: fixed compatibility problems with JDK 6 Update 12, VisualVM now works correctly with this JDK even without the VisualVM-Extensions plugin. Issue 242: CPU utilization chart in Monitor tab introduced in VisualVM 1.1 has been fixed to display correct values on multiprocessor systems. To get more information about the tool, download it and start using it, visit the project pages at https://visualvm.dev.java.net. If you want to provide some feedback to VisualVM developers, let them know on a mailing list.

VisualVM 1.1.1 tool has been released at https://visualvm.dev.java.net. This version delivers several important bugfixes and improves memory monitoring capabilities.    The most significant news are two...

Tips & Tricks

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 setupcons: 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 servicescons: 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: 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. 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. 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. 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 servicescons: 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: 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. 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. 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. 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.

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...

Features

New Command-Line Options in VisualVM 1.1

Recently released VisualVM 1.1 tool introduces three new command-line options: --openfile, --openpid and --openjmx. These options allow to use VisualVM as an application or file viewer. This can be handy especially for viewing heap dumps and thread dumps or for integration with third-party tools. A nice feature of VisualVM command-line support is the ability to reuse already running VisualVM instance. If you request to open a file for the first time, VisualVM is launched and the file is opened. If you request to open another file, it will be opened in the tool which is already running. This is possible thanks to the NetBeans Command Line Parsing API used by this feature. The --openfile option syntax: visualvm --openfile [filename] where filename is full path to a supported file allows to open a supported file in VisualVM. Supported are the same file types as in the Load dialog in VisualVM GUI - by default thread dumps (.tdump), heap dumps (.hprof) and profiler snapshots (.nps) are supported. Since the heap dumps are recognized by the file header and not just according to their extension, also .bin and other heap dumps can be opened by VisualVM. If a third-party tool adds support for another file type, it will be automatically available also from the command-line. The --openpid option syntax: visualvm --openpid [pid] where pid is process id of running Java application allows to open local Java process in VisualVM. This is an alternative to the Open action in VisualVM GUI. Note that there's a predefined timeout 5sec for which the VisualVM waits for the PID to become available - this allows to start VisualVM along with the monitored application. The --openpid option may be used for example in batch commands for monitoring several predefined applications (application servers etc.) or for integration with third-party tools (like the integration module for the Eclipse IDE). The --openjmx option syntax: visualvm --openjmx [hostname:port] where hostname:port defines the JMX connection allows to connect to local or remote Java process using the JMX connection. This is an alternative to the Add JMX Connection action in VisualVM GUI. JMX connection defined from the command-line is not restored after restarting VisualVM. The --openjmx option may be used for example in batch commands for monitoring several predefined applications (application servers etc.) or just like a simple remote application monitor/viewer.

Recently released VisualVM 1.1 tool introduces three new command-line options: --openfile, --openpid and --openjmx. These options allow to use VisualVM as an application or file viewer. This can...

News

VisualVM 1.1 Released

New version of the VisualVM tool has been released. VisualVM 1.1 introduces many new features and improvements, extends the API for plugins and delivers a complete JavaDoc documentation. Now integrates with the Eclipse IDE and IntelliJ IDEA!    These are the new features of VisualVM 1.1 as mentioned in the Release Notes: Monitoring CPU usage and Garbage Collector activity for each application in the Monitor tab Table view in the Threads tab (introduced by the NetBeans profiler 6.5) Three commandline options to enable using VisualVM as an application or snapshot viewer: --openpid <pid> starts VisualVM if not already running and opens a Java application with the process id --openjmx <hostname:port> starts VisualVM if not already running and opens a Java application defined by a JMX connection --openfile <file> starts VisualVM if not already running and opens a supported file (\*.tdump, \*.hprof, \*.nps, \*.apps) Compare Memory Snapshots action available in Applications window context menu for two selected comparable snapshots About dialog allows to copy configuration information to clipboard and save the logfile to an external file IBM JVM can be monitored by VisualVM using a JMX connection Eclipse integration plugin which starts VisualVM along with the monitored application directly from the IDE Integration with IntelliJ IDEA is already available, see the Profiler Plugin by Esko Luontola Experimental support for HP-UX PA-RISC platform (incl. profiling) The last significant change is using the latest NetBeans Platform and profiler 6.5 - this means many framework and profiler bugfixes being available also in VisualVM. VisualVM 1.1 can be downloaded at https://visualvm.dev.java.net. Feedback to VisualVM developers can be sent using this mailing list. The online JavaDoc documentation can be found here. Note that there's also a Releases Overview page available which lists all VisualVM releases and shows which VisualVM version is included in JDK as Java VisualVM.

New version of the VisualVM tool has been released. VisualVM 1.1 introduces many new features and improvements, extends the API for plugins and delivers a complete JavaDoc documentation....

Features

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.

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...

Features

Profiling With VisualVM, Part 1

This article describes the out-of-the-box profiling features of the VisualVM tool available without any additional configuration, just using the default settings. Beside various monitoring features, the tool contains a built-in profiler based on the NetBeans profiler. While the profiler UI in VisualVM looks simple (especially when compared to the NetBeans profiler), the profiling capabilities are almost as powerful as in NetBeans. The main difference between these two tools is their workflow: whereas NetBeans profiler is project/sources-centered and is a great tool for iterative testing/improving performance during application development, VisualVM can be used as a standalone profiler which works with any running application without having any context of the source code. Note: For profiling applications running on JDK 6.0 Update 6 and earlier, the applications need to be started with the Xshare:off flag which disables the class sharing, otherwise the profiling may cause a crash of profiled JVM. For applications running on JDK 6.0 Update 7 and higher the profiling should work without any modifications. The profiling UI is very simple, by default it shows just three buttons for analyzing performance (CPU button), memory usage (Memory button) and stopping the profiling session (Stop button). The other UI elements are Status area where the actual profiling status is shown and Profiling results section which displays live profiling data collected during the profiling session. For advanced profiling there's also a Settings section which is hidden by default. It allows to fine-tune the profiling settings, this is described in detail in Profiling With VisualVM, Part 2 article. Note: Whereas the Profiler tab is available for each application which can be profiled, only one application can be profiled at a time, concurrent profiling sessions are not supported. Profiling Performance When the CPU button in Profiler tab is pressed, the profiler attaches to the application and starts profiling its performance. At the beginning the profiler needs to instrument some methods of the application, the actual number of instrumented methods is displayed in the Status area. Since the profiler uses dynamic instrumentation, the number of instrumented methods may change during the profiling session. After the profiler is attached and starts collecting the data, the view looks like on the screenshot: You can see live profiling data for the application, for each profiled method number of invocations and total execution time is displayed. Note that not all methods are profiled, by default the profiler doesn't profile methods from java.*, javax.*, sun.*, sunw.*, com.sun.* (+ com.apple.*, apple.awt.* on Mac OS X) packages. Time spent in methods from these packages is added to execution time of profiled methods calling them, for example constructor execution time of a custom class (CustomClass.<init>) includes execution time of super constructor etc. The toolbar of Profiling results section contains the following actions (from the left): Update Results Automatically: results are periodically refreshed approx. each 1.2sec Update Results Now: immediately fetches actual data, typically used when automatic refresh is disabled Run Garbage Collection: invokes GC in profiled application Reset Collected Results Buffer: resets the data collected so far, useful for measuring delta results Take Snapshot of Collected Results: saves all the collected data into a persistent snapshot for more detailed analysis Save current view to image: saves the results table into a .png image The most important action is Take Snapshot of Collected Results (available also as Profiler Snapshot in context menu of profiled application in Applications tree). It takes a snapshot of collected profiling results (compatible with NetBeans profiler snapshot) and opens it in a separate tab. This snapshot provides several different views: Call Tree displaying methods call tree starting by threads, Hot Spots displaying a list of all profiled methods sorted by their execution time and Combined view showing both call tree and list of profiled methods. The last view Info displays basic snapshot information and detailed profiling configuration of the snapshot. There's one handy action available in context menu of each method, it's called Show Back Traces and displays all the places from where the method is being called.    Multiple profiler snapshots can be taken for a single profiling session for example to compare performance in various situations / loads / configurations of the application. All the profiler snapshots can be then saved into a single Application Snapshot (use Application Snapshot action in context menu of profiled application in Applications tree) to archive them in one file or to send them to application developers/quality engineers. Profiling Memory When Memory button in Profiler tab is pressed, the profiler attaches to the application and starts profiling its memory consumption. At the beginning the profiler needs to instrument all classes of the application, the actual number of instrumented classes is displayed in the Status area. Because all the application classes need to be instrumented, it takes some time until the profiler starts to collect the data. To lower the profiling overhead, each 10th object allocation is tracked by default (also displayed in Status area). Keep this in mind when evaluating the profiling results. After the profiler is attached and starts collecting the data, the view looks like on the screenshot: You can see live profiling data for the application, for each class number of live instances and their size is displayed. The rightmost column shows Surviving Generations metrics which is very useful for detecting memory leaks. Detailed explanation of Surviving Generations is available in this article. You can also monitor allocations history of a particular class during time (History subtab at the bottom), to do this invoke the Log Class History action in context menu of the class. The toolbar of memory profiling results is the same as for CPU profiling results. You can also save the collected results into a snapshot using the Take Snapshot of Collected Results action in Profiling results section toolbar or Profiler Snapshot context menu action. This is especially useful for detecting memory leaks, using the Compare Memory Snapshots action available in File menu you can visually display the difference between two comparable memory results and for example evaluate if/which objects remained on the heap after executing some action. Note: When stopping the profiling session (both CPU an Memory) the profiler restores original application bytecode. This can take some time and the application and/or the whole system may not respond for a while. Profiler Calibration When VisualVM is started for the first time, the profiler performs an initial calibration. During this process the overall system and actual JDK performance is being measured and these data are later used to subtract the profiling overhead from collected performance data. The profiler requires a "stable" performance of the system, this means that any technique for dynamic CPU frequency switching like SpeedStep or PowerNow! should be disabled during both the calibration and profiling. If the system performance changes or a different JDK than the calibrated one is used for profiling, the collected performance results may become biased and the profiler needs to be re-calibrated. Unfortunately there's no UI action available for recalibration in VisualVM 1.0, the only way to invoke the calibration again is to manually delete calibration data file in <user_directory>/.nbprofiler/machinedata.jdk1X and restart the VisualVM. 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 Profiling Results - Application Performance, Profiling Results - Memory Usage, CPU Snapshot or Memory Snapshot sections.

This article describes the out-of-the-box profiling features of the VisualVM tool available without any additional configuration, just using the default settings. Beside various monitoring features,...

News

VisualVM 1.0 Released

VisualVM 1.0 tool has been released at https://visualvm.dev.java.net. VisualVM is a free opensource visual tool integrating several commandline JDK tools and lightweight performance and memory profiling capabilities. Designed for both production and development time use, it further enhances the capability of monitoring and performance analysis for the Java SE platform.    The main features as listed on the Features page are: Displaying local and remote Java applications Displaying application configuration and runtime environment Monitoring application memory consumption and runtime behavior Monitoring application threads Profiling application performance and analyzing memory allocation Taking and displaying thread dumps Taking and browsing heap dumps Analyzing core dumps Analyzing applications offline VisualVM is designed as an extensible tool, new features can be easily added using a built-in Plugin Center. There are some useful plugins already available, for example the MBeans browser. All available plugins are listed on Plugins page. The tool is built on NetBeans Platform which together with VisualVM APIs makes it very easy for the developers to create new plugins. There are three main typical users of VisualVM: Application developers who can use VisualVM for profiling the applications, taking and browsing thread and heap dumps or just monitoring application runtime environment and behavior, System administrators who can use VisualVM for monitoring and controlling local and remote applications across the entire network using jvmstat or JMX technologies, Java application users who can use VisualVM to generate application snapshots containing all the data necessary to diagnose and fix bugs    Together with VisualVM 1.0 release the tool has also been released as Java VisualVM, a new JDK tool first available in Sun JDK 6 Update 7 which can be downloaded from this link. In initial releases these tools are identical, but in the future Java VisualVM will be a stable tool tested with each JDK distribution, whereas VisualVM will be a bleeding-edge distribution with the latest features and bug fixes. To get more information about the tool, download it and start using it, visit the project pages at https://visualvm.dev.java.net. If you want to provide some feedback to VisualVM developers, let them know on a mailing list.

VisualVM 1.0 tool has been released at https://visualvm.dev.java.net. VisualVM is a free opensource visual tool integrating several commandline JDK tools and lightweight performance and...

Tips & Tricks

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 applicationThis 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 pidhowever 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.

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:+HeapDumpOnOutOfMemoryErrorHotSpot VM...

News

NetBeans Profiler at JavaOne 2007

We would like to make a summary of Profiler participation at this year's JavaOne conference and let you know what we've presented there:NetBeans Day: at NetBeans Day there was a presentation of new features introduced in upcoming NetBeans IDE 6.0. As a part of this presentation we've presented what's new in Profiler 6.0: Profiling Points, Areas of Interest, Dynamic Attach, Load Generator support, HeapWalker and of course integration into NetBeans IDE as a standard built-in feature. For each major feature we've shown a short demo.Technical Session: we've made a technical session Quick and Easy Profiling with Integrated Tools (TS-9555) where we've shown how easy is to profile applications using a profiler integrated into the IDE. Using NetBeans Profiler 5.5 and NetBeans Profiler 6.0 Milestone 9 we've shown two real-world case studies: detecting a memory leak and fixing performance problem in large application.BOF: we've presented Visualize Runtime Problems: A New All-in-One JDK Troubleshooting Tool (BOF-9123) together with Mandy Chung, senior staff engineer at Sun Microsystems working on the Java SE monitoring and management and other serviceability technologies. VisualVM is a codename for new standalone monitoring & troubleshooting tool developed by NetBeans Profiler team. It contains tools for detecting localy and remotely running Java applications, displaying their runtime environment and behavior and tools for detecting runtime problems - profiler, heapwalker and other tools. We will describe this tool in more details later here.We've also attended a BOF related to a tool called MemoryLint, which searches for defined patterns in heap dump and reports problems like duplicated Strings or leaking HashMaps etc. This tool uses our HeapWalker's heap model, that's why we were interested in it. Because there was a lot of interest about this tool in the audience, we've decided to add experimental support for this tool in HeapWalker. It will be available in the upcoming NetBeans IDE 6.0 Milestone 10.

We would like to make a summary of Profiler participation at this year's JavaOne conference and let you know what we've presented there: NetBeans Day: at NetBeans Day there was a presentation of new...

Features

What Do The Surviving Generations Metrics Mean?

In VM Telemetry graphs of the Profiler you can see Surviving Generations metrics which can detect potential memory leaks. Here's a three-lines definition of the what the metrics mean:a Generation is a set of instances created within the same GC interval (between two garbage collections)a Surviving Generation is a Generation that survives at least one garbage collection. The number of survived garbage collections - the generation's age - is its unique identifierSurviving Generations (metrics) value is the number of differerent Surviving Generations that are currently alive on the heap (number of Generations with different generation ages)Typically there are several long-lived objects (like an application's main JFrame etc.) in an application representing one or a few Surviving Generations. There are also many short-lived objects created very frequently (such as Dimension etc.) and released soon, typically within only a few garbage collections. They also represent just several Surviving Generations.After some period of time the number of Surviving Generations in an application should become stable because all long-lived objects have already been created and newly-created short-lived objects are periodically being released from the heap. However, if there is a memory leak in an application which prevents newly-created objects from being released from the heap (for example objects stored in a Collection and never removed), the number of Surviving Generations grows and that's exactly what the Surviving Generations metrics is able to detect regardless of how much memory is wasted by such a leak.Note: This is an excerpt from an article published at netbeans.org. You can read the full story with a simple four-steps tutorial here.

In VM Telemetry graphs of the Profiler you can see Surviving Generations metrics which can detect potential memory leaks. Here's a three-lines definition of the what the metrics mean: a Generation is a...

Tips & Tricks

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<property.name>. 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.

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...

Tips & Tricks

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 netbeans.org 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.Download and install NetBeans IDE 5.5 and NetBeans Profiler 5.5.Follow these instructions to download javac source code and open it as a project in the IDE.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.Edit the javac buildscript build.xml: append target profile for example below target build-bin.javac.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/applicationapp.mainclassfile: relative path to mainclass java file of profiled project/applicationapp.srcdir: relative path to profiled project/application source rootapp.builddir: relative path to profiled project/application compiled classes root

Two weeks ago Sun Microsystems announced opensourcing href="http://openjdk.dev.java.net/">key Java implementations including javac, the Java programming language compiler. Youcan get the javac source...

Tips & Tricks

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:   -agentpath:​path_to_agent_library=​path_to_profiler_lib_dir,​comm_port_number​[,timeout_in_secs]wherepath_to_agent_library is full path to Profiler agent binary, on Windows %NB_INSTALL%\\​profiler1\\​lib\\​deployed\\​jdk15\\​windows\\​profilerinterface.dllpath_to_profiler_lib_dir is full path to Profiler lib directory, on Windows %NB_INSTALL%\\​profiler1\\​libcomm_port_number is Profiler agent communication port, must meet the value set in Profiler Options, default is 5140timeout_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 timeoutThe 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.

Anytime the profiled application is started for Profiler direct attach, the -agentpath argument of javacommand is used to load the Profiler agent into JVM. For Profile Project action this happens...

Tips & Tricks

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\\​"",5140However, 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:-agentpath:C:\\​PROGRA~1\\​netbeans-5.0\\​profiler1\\​lib\\​deployed\\​jdk15\\​windows\\​profilerinterface.dll=C:\\​PROGRA~1\\​netbeans-5.0\\​profiler1\\​lib,5140Whereas 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.

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...

Tips & Tricks

ComponentListener vs. HierarchyListener

Did you ever need to tweak component properties immediately after it appears on the screen? It seems to be quite trivial task but it took me a while till I found the right way how to do it.The problem was to obtain a notification that the component has been shown. I used java.awt.event.ComponentListener (ComponentAdapter) and its componentShown event - it worked quite fine but never reported the event for the very first time the component was shown. component.addComponentListener(new ComponentAdapter() {public void componentShown(ComponentEvent e) { System.out.println("Component shown"); } });What's the cause? The componentShown event is fired every time component's visibility - value of java.awt.Component.isVisible() - is changed. When the component is created, its isVisible() returns true, so no change happens when it's displayed for the first time.The correct property I needed to listen on is java.awt.Component.isShowing(). Its value is false unless the component is really showing on the screen. But there didn't seem to be any appropriate listener - ComponentListener.componentShown() actually does "componentMadeVisible()", but where is the real "componentShown()" implemented?After some time of googling I finally found a solution: java.awt.event.HierarchyListener. It has just one event hierarchyChanged which doesn't seem to be much useful, but all the magic is hidden in java.awt.event.HierarchyEvent which is passed to the method. Among other pure hierarchy-related stuff there is a SHOWING_CHANGED flag which "Indicates that the HIERARCHY_CHANGED event was generated due to a change in the showing state of the hierarchy". In other words it's a listener for Component.isShowing() property. component.addHierarchyListener(new HierarchyListener() {public void hierarchyChanged(HierarchyEvent e) {if ((e.getChangeFlags() & HierarchyEvent.SHOWING_CHANGED) != 0) System.out.println("Component shown"); } });Now I was finally able to change anything about the component after it was shown for the first time.

Did you ever need to tweak component properties immediately after it appears on the screen? It seems to be quite trivial task but it took me a while till I found the right way how to do it. The problem...

Oracle

Integrated Cloud Applications & Platform Services