Java Profiler Features
General
CPU profiling
Thread and synchronization issues
Memory profiling
Exception profiling
Garbage collection profiling
Probes
IDE integration

On demand profiling

Many existing profilers are very heavyweight and cannot be run in production, but only doing testing. And there is a cumbersome process of running the application within the profiler.

Effectively running a profiling tool that has high overhead causes a large amount of problems, as it can often take hours to properly get the tool to a point in a project where the failure occurs.

YourKit Java Profiler optimizes the process by profiling where, when and what is needed. CPU profiling adds no performance overhead to the application being profiled until profiling is explicitly started. You can start and stop CPU profiling during execution of Java application as many times as you wish.

YourKit Java Profiler streamlines the memory profiling process by making object allocation monitoring an option. This greatly reduces the amount of system resources needed to profile an application, and increases the overall performance and speed of the profiling job in general. It is so lightweight that can be considered "zero overhead".


Easiest installation and configuration

In our view, profiling should be non-intrusive and very easy to use. During today's fast track development, this is invaluable to allow developers to seamlessly integrate profiling into development process.

The profiling can be done at the will of the developer, at any point during an applications run time. This allows for a much lower impact on system resources, lower time consumption, and a more precise profiling of the application.

No need for cumbersome installations and separate run processes like traditional profilers.


Unlimited profiling for one fee

Commercial license allows running of an unlimited number of Java applications with the profiler agent in development, testing or production stages.


Profiling of Java EE applications

Action "Tools | Integrate with Java EE Server..." automatically enables profiling in a number of popular application servers:

  • Geronimo
  • JBoss
  • Jetty
  • JRun
  • Orion
  • Resin
  • Sun Application Server / GlassFish
  • Tomcat
  • WebLogic
  • WebSphere

If your server is not on the list, use the "Generic server" option.

If Java EE server runs on a remote machine, use a console version of Java EE integration wizard. This feature is invaluable when you have only telnet/ssh etc. access to the remote machine. Then you will be able to run the profiler UI on your workstation and profile the server remotely.

Also you can automatically run Java EE server with profiler from within your IDE with the help of IDE integration.

Read more...


Ability to profile in production environment

Extremely low overhead allows production code profiling.

If profiled code is obfuscated, profiler can automatically restore the original names of classes, methods and fields. Currently, we support RetroGuard, Zelix KlassMaster, ProGuard, yGuard.


Rich multiplatform support

Both YourKit Java Profiler and the profiled application can run on the following platforms:

  • Windows, 32-bit Java (x86) and 64-bit Java (x86-64):

    • Windows 8.1
    • Windows Server 2012 R2
    • Windows 8
    • Windows Server 2012
    • Windows 7
    • Windows Server 2008 R2
    • Windows Vista
    • Windows Server 2008
    • Windows XP
    • Windows Server 2003
  • Linux, 32-bit Java and 64-bit Java:

    • x86/x86-64
    • ppc/ppc64
    • ARM
  • Mac OS X 10.4 and newer, Intel, 32-bit and 64-bit Java
  • Solaris 9 and newer, SPARC, 32-bit and 64-bit Java
  • Solaris 10 and newer, x86, 32-bit and 64-bit Java
  • FreeBSD 7 and newer, i386 and amd64 (aka x86-64)
  • HP-UX IA64, 32-bit and 64-bit Java
  • AIX, 32-bit Java (ppc) and 64-bit Java (ppc64)

It is even possible to have 'mixed' configurations.

For example, you can start profiler on a Windows desktop and profile server running Linux or any combination thereof.

Supported Java versions:

  • Sun/Oracle Java 1.3, 1.4, 5, 6, 7, 8
  • JRockit 5 and 6
  • IBM Java 5, 6, 7

For detail see supported Java version matrix


32-bit and 64-bit Java support

32-bit and 64-bit JVMs are supported on each of the supported platforms.


Telemetry

This feature allows viewing key information about an application in runtime within live graphs, providing details about memory, garbage collection activity, loaded classes, threads, as well as JVM and OS information.

Very useful and unique feature is that the telemetry information is remembered inside the profiler agent. This allows to connect to profiled application on demand, being able to discover how the application has behaved in the past.

When you are connected to profiled application, find telemetry tabs on the session panel.

CPU telemetry

Memory telemetry

GC telemetry

Exception telemetry

Summary tab


Automated profiling: profiler API, triggers, command line tool

The profiler offers several options to profile automatically, without human interaction and/or without using the profiler UI:

  • Profiler API allows to programmatically switch profiling modes and to store profiling results
  • Triggers allow you to configure actions to be automatically performed on following events:

    • execution of particular method
    • high CPU usage
    • high memory usage
    • out of memory exception
    • JVM start
    • JVM exit
    • timer

    The possible actions include:

    • log events to console, file, agent log or in-agent data storage
    • control profiling
    • capture snapshots
  • Command line tool can be used to control profiling without using the profiler UI, e.g. in case of profiling a remote server

Filters in CPU and memory views

Filters can be used in YourKit Java Profiler to reduce the depth of call trees. By skipping successive calls of e.g. standard library methods, you can give more focus to problematic methods of profiled application.

Filters are applied to views where method call stacks are shown, as well as to hot spot and method list views. With same snapshot you can use different filters or use no filters at all - you do not need to start a new profiling session for such a change. Views are automatically updated when filter settings are changed.

Use "Settings | Filters..." to configure filters.

Filters are used in runtime as well to reduce CPU tracing overhead.

See corresponding help topic for detail.


Improved learnability

It's easier for newbies to discover the power of the profiler thanks to the following new features.

Hint panel provides direct links to context-related Help topics.

Innovative master-slave view concept allows to see key information on a single screen.

This feature greatly improves usability.

For example, when a method is selected in upper table, you can immediately see back traces or merged callees in the slave view below.

Another example: in memory views immediately see paths from GC roots:


Remote profiling

YourKit Java Profiler provides an ability to profile applications remotely, i.e. in case the profiled application and the profiler UI run on different machines. For example, this is much useful when profiling a remote Java EE server from your workstation.

Snapshot captured on remote host can be automatically transferred via network to the local machine.

Read more about profiling remote Java EE applications.


Ability to export profiling results

You can export profiling results to external formats such as HTML, CSV, XML, plain text, either from within the profiler UI or automatically by using a command line tool.

Also, "File | Copy To Clipboard..." (Ctrl+C or another platform specific shortcut) action copies text of selected row in all trees and lists.


Summary, snapshot annotation and automatic deobfuscation

The "Summary" tab provides an overview of JVM properties and parameters of profiled application, as well as a summary of application telemetry information.

Automatic deobfuscation

If the profiled application is obfuscated, YourKit Java Profiler can automatically restore original names of classes, fields and methods if you specify the path to the obfuscation log file.

Snapshot annotation

The "Summary" view for a snapshot lets you store free-form text descriptions directly in the snapshot file.

See corresponding help topic for detail.


CPU telemetry

The "CPU" tab shows live CPU usage telemetry charts.

Also, you can learn what application was doing at particular moments of time with the help of thread stack traces available in telemetry graphs. This is extremely useful analyzing CPU or other resource consumption peaks that have already happened, without CPU profiling (sampling, tracing) turned on. However, this is not a replacement of CPU profiling when you need most accurate and detailed results.

When profiling is started, the profiling results are immediately available as a call tree with threads merged, as well as method list:

This live view provides only basic information. To perform comprehensive analysis capture performance snapshot.

Read more about CPU profiling.


Sampling and tracing

You can choose either of the two available measurement modes: sampling or tracing.

When sampling is used, the profiler periodically queries stacks of running threads to estimate the slowest parts of the code.

Sampling is typically the best option when your goal is to locate and discover performance bottlenecks. With sampling, the profiler adds virtually no overhead to the profiled application.

When tracing is used, the profiler instruments the bytecode of the profiled application for recording thread CPU time spent inside each profiled method. Both times and invocation counts are available.

Read more about CPU profiling.


Java EE high-level statistics

You can profile applications in high-level terms like SQL statements and URLs. Read more...


CPU views: hot spots, method call tree and method list

CPU view ("View | CPU") shows CPU consumption details.

"Call tree (all threads together)" section shows top-down call tree with all threads merged.

"Call tree (by thread)" section shows top-down call tree for each thread.

"Hot spots" shows methods that consumed the most of CPU time.

"Method list" for each method shows its CPU time, own CPU time and, if recorded, invocation count.

See corresponding help topic for detail.


"Callees list" view

Callees list slave view shows which methods were called from certain methods. It is available as a slave view in:

  • Call tree
  • Hot spots
  • Method list

"Merged callees" view

Quickly gain knowledge about behavior of a certain method. Merged callees view shows merged call traces started from the method. This gives a summary of method execution, of its "overall" behavior.


Method back traces view

Back traces view shows all places in code where a certain method was called.


Ability to ignore particular methods or focus on particular methods only

Analyze CPU profiling results, ignoring particular methods or focusing on particular methods only

See corresponding help topic for detail.


CPU usage estimation

You can estimate CPU usage in given time range, basing on available stack trace telemetry:

Unlike CPU sampling, which should be explicitly started to obtain results, CPU usage estimation results are always available, as long as stack telemetry is enabled.

This makes CPU usage estimation an ideal tool for analysis of anomalies such as CPU spikes, especially those which has already happened, so you do not need to turn CPU sampling or tracing on and try reproduce the spike.

See corresponding help topic for detail.


Ability to compare CPU snapshots

With YourKit Java Profiler, you can compare two arbitrary CPU snapshots.

See corresponding help topic for detail.


Probes

Get almost unlimited capabilities to analyze issues specific to your particular application, as well as automatically recognize problems typical to wide range of applications.

Find short description below. For more detail, please refer to Help.

  • Customizable to fit your needs

    Gather information about your application according to your own rules by setting up your custom probes.

    Probe class is a Java class intended to monitor different events.

    Bytecode instrumentation engine injects calls to your probes to the methods which you specified. You can access method parameters, method return value, the object for which the method is called, as well as intercept uncaught exceptions thrown in the method. This provides virtually unlimited capabilities to monitor applications.

  • Probes can be registered on startup or via API. Probe activity mode can be changed in runtime.

  • Recognition of typical issues is available out-of-the-box

    Recognize typical problems with the help of built-in probes which are ready to use out-of-the-box. Also, as the source code of the built-in probes is available, use it as a good example should you decide creating custom probes.

    Built-in probes allow to monitor:

    • Thread creation, start, name change
    • Class load and unload events
    • File stream-based I/O operations
    • File NIO channel-based operations
    • Random access file I/O operations
    • Socket I/O operations
    • Database activity (JDBC/SQL)
    • JSP/Servlet request processing
    • Long AWT/Swing events, which cause UI irresponsiveness

    Read more...

  • Inspections enable automatic high-level analysis of application basing on results obtained by the built-in probes. Previously, the "Inspections" were available for memory-related issues only.

  • Rich UI enables comprehensive analysis of probe results.

    There are several views offering different presentation of events. You can easily navigate between the views, opening selected event in different view, as well as in the telemetry graphs.

    Tables view shows events by table. If table has dependent tables, they are presented as slave views:

    Timeline view shows sequence of events from different tables, allowing to analyze nested and sequential events from different tables:

    Call tree view shows events distributed by stack trace. For each table it shows where and how many events have happened:

  • CPU usage estimation allows to estimate CPU usage in given time range, basing on available stack trace telemetry:
  • You can examine all recorded events, or focus on events intersecting with given event or group of events. For example, select event corresponding to particular servlet request, to see nested events such as database operations, file I/O, socket connections etc.

  • Scalability: to avoid infinite growth of collected data, the number of recorded events can be limited.

Thread telemetry

Use tab Threads to track the live threads.


Automatic deadlock detection

If a Java-level deadlock happens in the profiled application, it will be automatically detected:

See corresponding help topic for detail.


Monitor profiling

Monitor profiling allows analysis of synchronization issues:

  • which threads were calling wait(), and for how long
  • which threads were blocked on attempt to acquire monitor held by another thread (synchronized methods/blocks), and for how long

Monitor profiling results are shown in the "Monitor Usage" view. Results can be grouped by waiting thread, by blocker thread and by monitor class name.

See corresponding help topic for detail.


Memory telemetry

  • The "Memory" tab shows live memory usage statistics:
  • The bottom table on "Memory" tab provides a class instance count statistics - a quick overview of current heap state:

This view provides only basic information. To perform comprehensive analysis capture memory snapshot.

See corresponding help topic for detail.


Unique comprehensive objects view

Objects view allows comprehensively examine all objects in snapshot or certain subset of objects.

"Biggest objects (dominators)" view shows individual objects that retain most of memory. Save time and find the largest problems quickly. The objects are shown as a dominator tree. Read more...

This information can be useful to understand and reduce memory usage. In particular, this is useful to find memory leaks caused by individual objects. Sometimes it can be educative to learn about memory distribution in terms of individual objects.

Unique "Class list" view is a powerful tool for examining how memory is distributed among instances of different classes.

This view provides instant feedback about which classes of the profiled application are consuming the most of the memory, causing memory leaks etc.

Classes whose objects retain most memory are shown at the top, as the list is sorted by retained size.

On opening the view, estimated retained sizes are shown instead of exact sizes, which cannot be immediately calculated. The exact sizes may be obtained by using "Calculate exact retained sizes" balloon above the "Retained Size" column. However, for most classes the estimation is very close to the exact value, so there is almost no need to run exact size calculation.

"Merged paths" view is a tool for examining how objects are retained. It is especially useful when analyzing objects of classes with big number of instances, such as int[] or java.lang.String etc.

"Merged paths" is similar to "Paths from GC roots" view, but unlike it shows not paths through individual objects, but paths from multiple objects grouped by class.

"Object explorer" shows all objects of the set and allows to browse their outgoing references. Outgoing references of an object are fields or array elements of the object that point to other objects.



"Incoming references" shows all objects of the set and allows to browse their incoming references. Incoming references of an object are references to that object.

"Class loaders" shows objects grouped by class loader. This view can help solving issues such as leaked loaders.

See corresponding help topic for detail.


Easy way to browse instances of particular class

Use "Memory | Instances by Class..." (Ctrl+N) action to browse all instances of particular class. It is also very useful when you want to check whether instances of certain class exist or not.

The camel humps notation is supported.


"Find Paths" helps to find reasons of memory leaks

YourKit Java Profiler has unique and very powerful means for memory leak detection - calculation of paths between objects in memory. To find the reason of the leak examine path from GC roots to a leaked object.

You can choose number of shown paths from the list above the view.

You can also find paths between defined sets of objects.

You can ignore particular references in paths. This feature is a great aid when investigating memory leaks, because it immediately shows whether nulling particular reference eliminates the leak, and if not, which remaining references you should also consider.

See corresponding help topic for detail.


Find objects by text pattern

"Memory | Strings by Pattern... (Ctrl+F)" action shows instances of java.lang.String, char[] and byte[] that match given text pattern. The objects can be found in entire snapshot or in custom objects set. This can be useful to locate particular objects if their fields refer to a known string.


Optional recording of object allocations

The profiler can optionally record object allocations, i.e. track method call stacks where objects are created. Since recording of allocations can impact performance of application being profiled, you can turn this mode on only for the periods when it is needed.

Object allocation recording is used to find sources of excessive garbage allocation and analyze where live objects are created.

If allocations are recorded, Objects view will appear with additional section:

The Garbage Collection view is a good starting point to search for excessive garbage allocation. It shows numbers and shallow sizes of collected objects, i.e. objects created since object allocation recording was started and recycled to the moment of snapshot capture. See Solving performance problems to learn more why one should avoid excessive garbage allocation.

See corresponding help topic for detail.


Automatic inspections

Typical problems can be recognized with the help of the "Inspections" feature. Inspections enable automatic high-level analysis of profiled application snapshots. Each inspection automatically detects a specific issue. Performing this type of analysis by hand would be a very complicated (if at all possible) task.

See corresponding help topic for details.


Object generations

The generations distribute objects by time of their creation, and thus they are very helpful finding memory leaks and doing other analysis of how heap content evolves in time.

When each object is created, it is associated with current generation number. The generation represents object's age: the smaller the generation number, the older the object.

All tabs representing live objects have "Generations" view. In this view, you get objects separated by time of their creation:

See corresponding help topic for details.


Reachability scopes

Distribute objects according to how/whether they are reachable from GC roots:

  • Strong reachable
  • Weak/soft reachable
  • Dead objects: unreachable from GC roots, but not yet collected
  • Objects pending finalization

This information is helpful when analysing the profiled application's memory consumption and searching for memory leaks. Also it helps examining excessive garbage allocation, especially if the snapshot doesn't contain recorded object allocation information.

See corresponding help topic for details.


"Quick Info" view

"Quick Info" view shows useful information about selected object(s), such as:

  • Retained and shallow size
  • Object count
  • Allocation trace, if available
  • Stack traces, if there are local variables referencing to the selected object, as well as the variable names, if corresponding debug info is available
  • Object generation information, if available
  • Primitive array elements

Ability to automatically capture snapshots on event

You can instruct the profiler to trigger capturing of snapshots.

There are 3 kinds of triggers available:

  • Capture snapshot on high memory usage
  • Capture on OutOfMemoryError
  • Capture snapshots periodically

The triggers can be set up and later altered during profiled application run time.


When triggered memory snapshot is captured notification is shown in UI:

See corresponding help topic for detail.


Ability to compare memory snapshots

With YourKit Java Profiler, you can compare two arbitrary memory snapshots.

See corresponding help topic for detail.


Automated comprehensive memory tests

YourKit's descriptive XML based language allows users to declare custom sets of objects in order to find memory leaks and examine memory distribution.

The descriptive language for memory analysis and profiler API allow to write comprehensive memory tests.


Support of HPROF format snapshots

Java has a built-in feature - under certain circumstances, to save memory dumps into files in so-called HPROF format. You can analyze these files using all of the powerful features that YourKit Java Profiler provides for its own memory snapshots.

HPROF format memory dumps can be created in the following ways:

  • On OutOfMemoryError
  • Explicitly from within the profiler UI (Java 6)
  • Explicitly via jmap utility (Java 6)
  • Explicitly via jconsole utility (Java 6)

See corresponding help topic for detail.


Values of primitive types

Primitive fields (int, boolean, double etc.) and primitive array elements are shown in object explorers:

For byte[] Quick Info shows text representation in specified encoding:

See corresponding help topic for detail.


Exception telemetry

"Exceptions" telemetry shows exceptions which were thrown in the profiled application.

See corresponding help topic for detail.


Garbage collection profiling

"Garbage Collection" telemetry will help you estimate garbage collector load. If garbage collection takes a significant amount of time, it is advised to profile memory allocation to pin-point and optimize the problematic code.

See corresponding help topic for detail.


IDE integration

IDE integration provides:

  • Ability to launch profiled applications from within the IDE thus making CPU and memory optimization a part of your development process
  • Easy navigation from profiling results to underlying source code of profiled application -- "Tools | Open Declaration in IDE Editor (F7)" action opens currently selected class, field or method in IDE editor

Supported IDEs:

When profiled application is launched from IDE, the profiler UI automatically opens and connects to the application (If found obtrusive, this option can be turned off from plugin UI)

If profiled application launched from IDE ends quickly, the profiler UI will anyway show the application's profiling results.