This document will walk you through the process of profiling a
standalone Java application, web application and Java applet
using VisualVM for MyEclipse, an advanced integration of Sun's
VisualVM is included in MyEclipse but might not be part of your
base install configuration. You can check that it is installed from
the MyEclipse Software Configuration Center within MyEclipse itself. The configuration
center is available from the Help menu. However, if you notice portions of this tutorial
looking different than the screens you are seeing, please
let us know and we will make sure to
resolve any inconsistencies.
To be reliably profiled, your application must be executed using
JRE 1.6.0 update 7 or higher.
Profiling standalone Java applications
In this tutorial, we will be profiling the
M4MContactManagerExample application which you can download from
our Examples On Demand service; you may also follow along with an
application of your choice instead. To download this application,
MyEclipse > Examples On-Demand, scroll down
to the M4MContactManagerExample and click
Install Project to check it out into your
Select the M4MContactManagerExample project and right click to
bring up the context menu.
Profile As > Java Application to launch the
profiler in performance profiling mode.
When asked, select
as the main class.
Select a few names in the contact manager application and
observe profiling information being collected in the VisualVM
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
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.
When finished with your analysis, you may close both the
application and VisualVM window.
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
Customizing Performance Profiling
To access advanced profiling settings, bring up the context
menu for your project and select
Profile As > Profile Configurations... or
Profile Configurations... from the Profile
Profile Configurations wizard, select your
application from the tree on the left, under the
Java Application node.
Profile tab and then the
Performance tab to change the profiler
Performance Profiling Settings
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.
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
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
Profile underlying framework at startup
If selected, the startup of the application's JVM is also
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
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
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
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.
Profile tab, followed by the
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
number of allocated objects of a particular class is
accurately tracked, complete profiling data is separately
tracked and is only collected for every X
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
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
A memory snapshot showing object allocation traces
Profiling web applications & Java applets
Bring up the context menu on your web project and select
Profile As > MyEclipse Server Application to
To customize the profiling settings, follow the same instructions
section 3, your web applications
profiling configuration can be found under the
MyEclipse Server Application node in the Profile
From the context menu of your applet project, select
Profile As > Java Applet to start profiling.
To customize the profiling settings, follow the same instructions
section 3, your applet profiling
configuration can be found under the
Java Applet node in the Profile wizard.
Other VisualVM features
Monitor tab contains an overview of your
application's current state, CPU and memory usage.
Thread tab contains a list of threads in your
You can drill down to get detailed information on a specific
thread as well.
Use the application's context menu to take a Thread or Heap dump
at that that point in time.
We would like to hear from you! If you liked this tutorial, have
some suggestions or even some corrections for us, please let us
know. We track all user feedback about our learning material in
Please be sure to let us know which piece of MyEclipse material
you are commenting on so we can quickly pinpoint any issues that