Profiling with VisualVM for MyEclipse

1. Introduction
2. System Requirements
3. Profiling standalone Java applications
4. Profiling web applications & Java applets
5. Other VisualVM Features
6. Feedback

Performance Profiling

1. Select the M4MContactManagerExample project and right click to bring up the context menu.
2. Select Profile As > Java Application to launch the profiler in performance profiling mode.

   

   When asked, select com.myeclipseide.examples.m4m.Main as the main class.
   
3. Select a few names in the contact manager application and observe profiling information being collected in the VisualVM window.
   
4. Select a name in the list and click Remove, you should now see the removeButtonActionPerformed method added to the list, with 1 as its invocation count. This count will increase each time you click the Remove button.

   

5. Click the Snapshot button to take a snapshot of the results collected at this time, you can save this to a file for later research if desired.

   

6. When finished with your analysis, you may close both the application and VisualVM window.
7. To re-run the profiling session, you can repeat step 2 or simply select this profiling configuration from the Profile drop down in the main Eclipse toolbar. If an application that was previously being profiled is still running, you will be asked to shut it down before launching another profiling session.

   

Customizing Performance Profiling

1. To access advanced profiling settings, bring up the context menu for your project and select Profile As > Profile Configurations... or select Profile Configurations... from the Profile drop down.

   

2. In the Profile Configurations wizard, select your application from the tree on the left, under the Java Application node.
3. Select the Profile tab and then the Performance tab to change the profiler settings.

   

Performance Profiling Settings
Profile from	This field is used to specify root methods that the profiler will use 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 will specify a root which includes all packages in your project.
Only / Do not profile the following classes	The profiling filter is used to control the packages which will (or will not) be profiled. Besides the root methods themselves, profiling data is only collected and displayed if methods satisfy the filters defined here. By default, MyEclipse will specify a filter which 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 startup	If selected, the startup of the application's JVM is also profiled.
Method tracking	During performance profiling, a method entry and method exit call is inserted into each instrumented method, these calls may 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: Here a timestamp is taken only if the method entry and method exit calls occur at the end of the specified sampling interval, method invocations are still counted accurately. Using 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 / setters	Enables instrumentation of getter and setter methods.
Instrument empty methods	Enables the instrumentation of methods which do not contain any executable code.
Profile new threads / runnables	If 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 is stopped. This counter can be reset by resetting the collected results in the profiler.

Memory Profiling

1. From your project's context menu, select Profile As > Profile Configurations... and select your project from the tree on the left under the Java Application node.
2. Select the Profile tab, followed by the Memory tab.

   

3. You may customize the settings and then click Profile to start memory profiling.

Memory Profiling Settings
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 will increase 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.

A memory snapshot showing object allocation traces