Changes in version 9.0 from 8.0:
- New Feature: Probes
- Memory Profiling
- CPU Profiling
- Telemetry
- J2EE Integration
- IDE Integration
- User Interface
- Miscellaneous
New Feature: Probes
-
Overview
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 and unregister on startup, via API or in the profiler UI with the help of "Manage Probes". Please use corresponding link in the right upper corner of the "Probes" tab when connected to profiled application.
-
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
-
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 sequental 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.
Memory Profiling
-
New feature: UI: ability to 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.
-
New feature: per-memory pool telemetry
-
New feature: ability to open Android HPROF snapshots,
converted to standard format with Android's
hprof-convutility -
New feature: UI: Class hierarchy slave view allows to see superclasses and extending classes for given class
-
New feature: UI: Class list has new slave view "Class statics", which allows to quickly browse static fields and constant pool references of selected class
-
New feature:
UI: action "Memory | View Selected Objects Class" (also available in popup menus)
opens classes (
java.lang.Classinstances) for selected object(s) - New feature: startup option disableoomedumper to disable on OutOfMemoryError snapshots
-
Improvement:
memory snapshots contain values of primitive types
on
Mac OS X too -
Improvement:
ability to capture HPROF snapshot with JVM built-in dumper
is now available on
Mac OS X too - Improvement: HPROF snapshots: object shallow sizes are calculated more accurately, taking into account some tricky cases of field alignment in memory. Note: if HPROF snapshot has index file created with an earlier version of the profiler, remove or re-create the index file.
- Improvement: thread, stack and local variable name information will be available for "Stack local" roots even if profiled application runs with debugger. In previous versions, this information was not available running with debugger.
- Problem solved: JRockit: improved handling of incorrect data provided by JRockit JVM under some rare circumstances, which could lead to crashes on memory snapshot capture. JRockit R27.5.6 is affected. It is possible that earlier versions of JRockit are also affected.
-
Problem solved: thread name was not shown for
some thread objects (i.e. instances of
java.lang.Threador subclasses) in reference explorers
CPU Profiling
-
New feature:
"What-if":
analyze CPU profiling results,
ignoring particular methods or focusing on particular methods only
-
New feature:
CPU usage estimation:
allows to estimate CPU usage in given time range, basing on available stack trace telemetry:
-
New feature: "Method list" is available in live view, in addition to "Call tree"
- New feature: CPU tracing: calibration helps to compensate CPU tracing overhead, excluding it from profiling results. The overhead is different for different platforms, JVM versions, vendors, for 32-bit and 64-bit JVMs, and can even depend on JVM options. The calibration is automatically performed for each running JVM instance, when CPU tracing is started first time. It takes approximately 1-2 seconds.
-
Improvement:
CPU tracing:
Mac OS X : native methods are included to the profiling results - Problem fixed: defective CPU tracing results could be produced on some Linux configurations due to incorrect thread execution times reported by operating system
Telemetry
-
Telemetry: an option to see time as clock (system time in profiled system)
in addition to uptime (time passed since profiled application start).
Switch the mode via graph's popup menu.
J2EE Integration
- New feature: GlassFish 3 supported
- Improvement: simplified profiling of applications running inside an OSGi container: there is no need to manually twick OSGi settings anymore to allow loading of the profiler classes
-
Improvement: J2EE Statistics:
an option to show/hide calls whose execution took less than 1 ms
- Improvement: Tomcat 6 support improved
IDE Integration
- New feature: NetBeans 6.8 supported
- New feature: MyEclipse 8.5 supported
- Improvement: integration wizard improved to handle some NetBeans configurations
-
Improvement: it is now possible to specify in the plugin UI whether a 32-bit Java or a 64-bit Java is used to launch profiled application, in order to choose appropriate profiler agent. Previously, it was required to re-run IDE integration wizard to change the JVM kind. Also, it is now possible to choose Java kind per run configuration in IDEs which provide such capabilities (Eclipse, IDEA). See tab "32-bit or 64-bit Java Selection" in the plugin configuration UI.
For example, see how the configuration looks in Eclipse:
... and in NetBeans:
Of course, IDEA and JDeveloper are also supported.
User Interface
-
New feature: Welcome screen: "Monitor Local Applications" panel provides an option to see all Java applications running on the machine, including those not started with the profiler agent. This greatly helps troubleshooting possible connection problems.
-
New feature: table columns are resizeable, and if column content does not fit, a scroller appears. Also, wide tables are scrollable themselves, like tables in spreadsheet applications.
This dramatically improves usability working with Probes results.
Another view to mention which will greatly benefit from this feature is Threads where very long thread names will not be cut off anymore.
- New feature: Summary tab: list of all system properties is available ("System properties")
-
Improvement:
Quick info:
an option to see non-filtered stack traces
-
Improvement: graphs are filled with color
- Improvement: profiler events such as switching profiling modes, starting/stopping profiling, capturing snapshots etc. are now logged to the log file, as well as are available in "Probes" tab in "Messages" table (categories "Profiler" and "Profiler UI")
- Improvement: Summary tab: Java version is shown with all available VM detail
-
Improvement:
desktop integration on
Mac OS X : ability to open exported files
Miscellaneous
- New feature: Java 7 supported
- New feature: HP-UX supported. Running profiled applications and/or the profiler UI is now supported on HP-UX on IA64 architecture. Both 32-bit and 64-bit JVMs are supported.
- New feature: ability to export basic snapshot views to *.csv, *.txt, *.html via a command line tool. For detail, see "Export with command line tool" here.
- New feature: "Settings | Snapshot Directory..." allows to configure snapshot directory location. Read more...
-
New feature:
now it is possible to combine exclusive and inclusive filter patterns,
i.e. to specify classes which must be filtered as well as classes which must not be filtered.
In the latest case, prepend the pattern with "+".
For example,
org.apache.*,+org.apache.jsp.*will filter out Tomcat internals, but will not filter classes of particular JSP pages, which Tomcat generates in packageorg.apache.jsp. -
New feature: profiler agent log is written to file
<user home>/.yjp/log/<PID>.loginstead ofstderr. Successfully started agent writes tostderronly the following line:This line can be suppressed using startup option[YourKit Java Profiler <version>] Loaded. Log file: <full path to the log file> 'quiet'.With this new approach, the profiler agent log messages are easier to find if profiled application redirects its output to own log files or filters it, and will not be lost if the output goes directly to console, or if there is no console at all if the profiled application runs as a service. Also, the profiled application's output and its own log files are not cluttered with extra messages.
-
(Since 9.0.3) New feature: periodic snapshot trigger allows to choose the kind of snapshot to capture: performance, memory in *.snapshot format or memory in HPROF format. Previosly, the periodic snapshot trigger only captured memory snapshots in *.snapshot format.
In particular, this feature helps to monitor long running applications. By default, telemetry buffer capacity is approximately 1 hour, and older telemetry is not available. Instead of increasing the telemetry buffer capabicty with "telemetrylimit" startup option, you can periodically capture performance snapshots to ensure that that oldest telemetry will not be lost.
-
New feature:
API:
added methods
com.yourkit.api.Controller.setPeriodicSnapshotTrigger()andcom.yourkit.api.Controller.getPeriodicSnapshotTriggerStatus()which enable programmatic access to the periodic snapshot trigger -
New feature:
API:
added methods
com.yourkit.api.Controller.getUsedMemoryThreshold()andcom.yourkit.api.Controller.setUsedMemoryThreshold()which enable programmatic access to on-low-memory snapshot trigger -
New feature:
API:
com.yourkit.api.Controller: added methodsclearCPUData(),clearAllocationData(),clearExceptions(),clearMonitorData() -
(Since 9.0.3)
Improvement: periodic snapshot trigger can be turned on from the start
with the help of startup options
,periodicperf=<period> ,periodicmem=<period>periodichprof=<period> - Improvement: Windows installer detects previously installed builds and offers to automatically uninstall them before installing the new one
-
Improvement:
API:
return type of
com.yourkit.api.MemorySnapshot.getShallowSize()changed frominttolong -
Improvement:
API:
com.yourkit.api.Controller.startCPUProfiling()can be instructed to use current filter and wall time settings stored in user home (~/.yjp/config/.filtersand~/.yjp/config/.walltimerespectively), by passing 'null' as parameters. See Javadoc for detail. -
Improvement:
Command line tool to control profiling:
when using "start-cpu-sampling" or "start-cpu-tracing" commands,
current filter and
wall time settings are read from user home
(
~/.yjp/config/.filtersand~/.yjp/config/.walltimerespectively), instead of always using default settings. -
Improvement: profiler UI settings can be specified in
bin/yjp.inion all platforms. Previously, it was required to modify different files on different platforms. -
Improvement:
non-Windows: improved diagnostic on attempt to start
yjp.shwith an outdated Java version -
Improvement:
Solaris:
yjp.shautomatically starts the profiler UI with a 64-bit JVM if it is available - Optimization: bytecode instrumentation improvements
- Caveat: only applications running on Java 6 or newer can be profiled. New functionality provided by this version of the profiler requires Java 6 APIs which are not available in earlier Java versions. For profiling Java 5 applications, please use YourKit Java Profiler 8.0.
- Problem solved: applications using scala might fail starting with the profiler, due to some odd bytecode patterns generated by scala compiler
- Problem solved: profiled application startup might fail using some builds of IBM Java 6 (e.g. some bundled with WebSphere)
- Bug fixed: profiled application might not start if its process identifier (PID) was bigger than 65536.

