Server Profiling with VisualVM for MyEclipse

MyEclipse includes an advanced integration of Sun’s VisualVM Profiler. Server profiling allows you to gather data about applications as they run and monitor data statistics.

Note: Server Profiling was removed in MyEclipse 2015 and subsequent versions.

  • Profile a stand-alone Java application
  • Profile a web application
  • Profile a Java applet

Duration Time: 20 Minutes

Start Tutorial Now

Don't have MyEclipse? Download Now

1. Make Sure the Profiler is Installed

VisualVM is included in MyEclipse, but might not be part of your base installation configuration. If not installed, you can easily add the component.
  1. Select Help>Choose Components.
  2. On the Selected side, type vm in the Filter field to find the MyEclipse VisualVM Profiler components. Checking for VisualVM Profiler software
  3. If VisualVM is not installed, add the component by selecting it on the left and moving it to the right side.
To be reliably profiled, your application must be executed using JRE 1.6.0 update 7 or higher.

2. Profiling a Stand-Alone Java Application

  1. Select MyEclipse>Examples On-Demand to download an example project for profiling.
  2. Click Search, and search for swing.
  3. Click the Install button for the Swing Contact Manager example to install it into your workspace. profiler_eod Installing sample application

2.1 Performance Profiling

  1. Right-click the M4MContactManagerExample project, and select Profile As>Java Application. This launches the profiler in performance profiling mode. Launching the performance profiling mode
  2. Select Main - com.myeclipseide.examples.m4m as the main class, click OK, and select Performance as the profiling mode. Click OK to continue.
  3. Select a few names in the contact manager application to observe profiling information being collected in the VisualVM window. Profile information collected when names are selected
  4. Select a name in the list, and click Remove to see the removeButtonActionPerformed method added to the list, with 1 as its invocation count. This count increases each time you click Remove. Results for using the Remove button
  5. Click to save a snapshot of the results collected at this time. Use the filter to display only the information you want to view. You can save this to a file for later research. Server profiling in MyEclipse Filtering snapshot information
  6. Close both the application and VisualVM window.

To run the profiling session again, you can repeat step 1, or click the drop-down arrow on the Profile icon . Select the profiling configuration you want to view. If an application that was previously being profiled is still running, you are prompted to shut it down before launching another profiling session.

Running an existing profile from the toolbar

2.2 Customizing Performance Profiling

  1. Right-click the project, and select Profile As>Profile Configurations, or click the drop-down on the Profile icon , and select Profile Configurations. Opening profile configurations
  2. Select your application from the list on the left, under the Java Application node.
  3. Select the Profile tab, and then the Performance tab to change the profiler settings. Performance profiler settings
Profile from This field specifies root methods the profiler uses to instrument your application. Only root methods and methods they call (recursively) are instrumented while the rest of the application continues to run un-instrumented. Use the Add button to specify a method, class or package. If a class is specified, then all methods in that class become instrumentation roots. If a package is specified, methods in all classes contained in that package become instrumentation roots (depending on your selection in the Profiling Root wizard, this could mean only the selected package or include sub-packages, as well). By default, MyEclipse specifies a root that includes all packages in your project.
Only / Do not profile the following classes The profiling filter controls the packages which are (or are not) profiled. Besides the root methods themselves, profiling data is only collected and displayed if methods satisfy the filters defined here.
By default, MyEclipse specifies a filter that includes only the packages in your project.Instrumentation Scheme You can choose between Lazy, Eager and Total instrumentation. Lazy (MyEclipse default): This is the best scheme for long running applications because of its low instrumentation overhead. When this scheme is used, the root methods are instrumented first. The first time a root method is executed, all the methods it calls are instrumented and so on. Total: In this scheme, all methods in a class are instrumented as soon as the class is loaded. This is not a good scheme to use for long running applications due to the high profiling overhead. However, it can be useful when working with short-lived applications and profiling application startup. Eager: In this scheme, whenever a class is loaded, the profiler locates and instruments all methods that could be reached directly or transitively by a root method. As a result the number of methods instrumented is much higher than the Lazy scheme but is still lower than the Total scheme. Profile underlying framework at startupIf selected, the startup of the application's JVM is also profiled.Method trackingDuring performance profiling, a method entry and method exit call is inserted into each instrumented method. These calls might take timestamps when called, depending on the tracking technique used.  Exact: With exact tracking, the entry and exit calls take a timestamp each time the method is called. This gives you accurate method execution time (time between the entry and corresponding exit call) readings, but increases profiling overhead due to the large number of calls to the OS high-precision timer. Sampled: A timestamp is taken only if the method entry and method exit calls occur at the end of the specified sampling interva. Method invocations are still counted accurately. This option significantly reduces the profiling overhead, but the accuracy of the results may be lower than those obtained using the Exact technique.

Instrument method invoke() If enabled, all calls made using reflection (java.lang.reflect.Method.invoke()) are followed and instrumented.Instrument getters / settersEnables instrumentation of getter and setter methods.Instrument empty methods Enables the instrumentation of methods that do not contain executable code.Profile new threads / runnablesIf enabled, the run() method of every runnable is treated like a root method, causing all methods called by it to be instrumented as well.Exclude time spent in Thread.sleep() and Object.wait() If selected, these methods are not profiled.Limit number of profiled threads Profiling data is only collected from registered threads. Whenever an unregistered thread enters instrumented code, it is registered. When the number of registered threads reaches the specified limit, further registration stops. This counter can be reset by resetting the collected results in the profiler.

2.3 Memory Profiling

  1. Right-click the project, select Profile As>Profile Configurations, and select your project from the list on the left under the Java Application node.
  2. Select the Profile tab, and then select the Memory tab. Memory profile settings
  3. Customize the settings, and then click Profile to start memory profiling.
Record object creation only When selected, the profiler collects information about the number, type and location of allocated objects. All classes currently loaded by the target JVM (and each new class as it is loaded) are instrumented.
Record object creation and garbage collection If this option is selected, in addition to the data presented by the above option, you are also given information about object liveliness, i.e. how many objects of a given type are still alive. Profiling garbage collection in addition to object creation increases the profiling overhead.
Track every X allocations While the number of allocated objects of a particular class is accurately tracked, complete profiling data is separately tracked and is only collected for every X th object (of that class) allocated. To record information about each allocation, this figure can be set to 1, though that increases profiling overhead significantly. By default, MyEclipse tracks every 10 th object allocation.
Record stack trace for allocation If enabled, when object creation is recorded, the call stack at that time is also recorded. By default, the entire call stack is recorded, but the Limit Stack Depth to X Frames option can be used to limit the number of frames and reduce profiling overhead.
Server profiling in MyEclipse
A memory snapshot showing object allocation traces

3. Profiling a Web Application

  1. Right-click a web project, and select Profile As>MyEclipse Server Application. Starting web application profiling
  2. To customize the profiling settings, follow the instructions in Section 2. Profiling configuration for your web application is found under the MyEclipse Server Application node in the Profile Configurations window. Server profiling configurations Profile settings for a web application

4. Profiling a Java Applet

  1. Right-click an applet project, and select Profile As>Java Applet. Starting Java applet profiling
  2. To customize the profiling settings, follow the instructions in Section 2. Profiling configuration for your Java applet is found under the Java Applet node in the Profile Configurations window.Server profiling configurations Profile settings for a Java applet

5. Other VisualVM features

The VisualVM's Monitor tab contains an overview of your application's current state, CPU, and memory usage.
Monitor tab
The Threads tab contains a list of threads in your application.
Threads tab
You can drill down to get detailed information on a specific thread as well.
Threads tab details
Click the Applications button in the margin, right-click your application, and select either Thread or Heap Dump.
Dumping the application
Thread dump
Heap dump