Changes in version 10 from 9.5:

• New Feature: Triggers
• Memory Profiling
• CPU Profiling
• Telemetry
• Probes
• IDE Integration
• User Interface
• Miscellaneous

New Feature: Triggers

• Advanced 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 data storage as probes do; there is a rich set of macros to be used to form the logged message
  • control profiling
  • capture snapshots
  
  

  Trigger editor offers templates of pre-configured sets of actions useful on certain events.

  

  In particular, previously existed built-in triggers to capture snapshots periodically or on high memory usage are now replaced with a more powerful triggers, and can easily be added using corresponding template. In particular, it is now possible to limit the number of periodic snapshots to capture, or capture more than one snapshot on high memory usage.

  Read more...

Memory Profiling

• New feature: allocation recording can gather the garbage collector statistics per class, i.e. it not only shows thread and stack where the collected objects were created, but also their classes.

  

  The per-class statistics is gathered by default when you start allocation recording. To reduce overhead there is an option to turn it off:

  • in the profiler UI: check box "Gather garbage collection statistics per-class" in the "Start Object Allocation Recording" toolbar popup window
  • startup option noperclassgc which disables per-class garbage statistics for allocation recording started with alloceach or allocsizelimit
  • API method Controller.startAllocationRecording(...) parameter boolean perClassGarbageStatistics. The old version of the method without that parameter has been deprecated.
• New feature: memory snapshots of applications running in the compressed strings mode (-XX:+UseCompressedStrings) are supported
• Generations: improvement: if application was started with the profiler agent, objects created during VM initialization are marked as generation "JVM initialization". If the agent was attached to a running application, objects created before the attach are marked as generation "Agent attached".
• Allocation recording: improvement: object allocation information for live objects is now available not only in memory snapshots captured when allocations are being recorded, but also in memory snapshots captured after allocation recording has been stopped
• Improvement: Merged paths view speed-up

• New feature: added ability to open memory snapshots as performance snapshots, i.e. to load all profiling data except for the heap content.

  In particular, memory usage telemetry, object by class counts and allocation information (if recorded) will be available.

  This feature helps working with huge memory snapshots:

  • if your machine is not capable of opening a huge memory snapshot, or opening takes too long, quickly get a look at memory usage statistics, as well as access all other profiling data possibly contained in the snapshot: telemetry graphs, CPU profiling results, monitor profiling results, exceptions, object allocation statistics, probe results etc.
  • the performance snapshot can be extracted to a file for further processing, or transfer to another machine; in case of a limited bandwidth, sending several megabytes instead of gigabytes is a great improvement

  Extracting performance snapshot from the profiler UI

  • To extract performance snapshot from a memory snapshot, select the memory snapshot file in the Open snapshot dialog and use action "Extract Performance Snapshot":

    

  • On attempt to open a big memory snapshot, the profiler offers an option to open it as a performance snapshot instead:

    

    If you choose this option, the performance snapshot will be extracted and opened. The effect will be the same as if you would explicitly invoke "Extract Performance Snapshot" and then open the resulting performance snapshot.

  • If you have fully loaded a memory snapshot, you can use File | Extract Performance Snapshot in the main menu to extract a performance snapshot and save it to file.

  Extracting performance snapshots with command line tool

  You can extract performance snapshot using the following command:

  java -jar <Profiler Installation Directory>/lib/yjp.jar -extract-performance-snapshot <memory_snapshot_file_path>

  Location of the extracted snapshots

  The resulted performance snapshots are created in the snapshot directory.

• Set description language: new tag generation returns objects from specified generations

  Examples:

  Objects from generation 3: <generation name="#3:*">

  Objects from all generation(s) with description "foo": <generation name="*: foo">

  All strings from generation #5:

  <and>
    <objects class="java.lang.String"/>
    <generation name="#5:*">
  </and>
        

• New feature: ability to capture HPROF snapshots with JVM built-in dumper is now available on FreeBSD too
• UI: improvement: the configurable number of array elements shown in object explorer now includes only non-null elements. This simplifies browsing of sparse arrays. Also, the default number has been changed to 15, it is configurable via -Dyjp.array.elements.to.show=value in <Profiler Installation Directory>/bin/yjp.ini.
• UI: improvement: instances of java.lang.ref.Finalizer constituting the finalization queue's linked list are now included to the objects pending finalization reachability scope instead of the strongly reachable objects scope, to better reflect their nature and life cycle

CPU Profiling

• Wall time settings format has been changed to accept human-readable method parameter lists instead of cumbersome JVM method signatures:
  
• CPU tracing calibration accuracy improved
• Improvement: added startup option deadthreadlimit to customize the number of recently finished threads for which CPU sampling, CPU tracing and monitor profiling results are kept (the default value is 50). Profiling results for the finished threads beyond this limit are merged to <Oldest finished threads> pseudo-thread node. The intention is to limit collected data size when profiling applications constantly creating new short living threads.

Telemetry

• New feature: added ability to filter Threads view by method.

  If method pattern is specified (it can be class name and/or method name and/or signature), samples with matching stacks are marked.

  There is an option to show only the threads with matching stacks.

  Also, the method filter affects the threads shown in the Stack traces tab, as well as the CPU Usage Estimation.

  CPU usage estimation provides an option to account samples in either all threads in the selected range or only in those matching the thread and method filter

• Improvement: CPU usage and time spent in garbage collector are shown on the same graph, indicating CPU usage peaks caused by the garbage collector activities.
  
• Improvement: Memory usage telemetry: G1 GC per-pool usage graphs reordered, placing eden generation graph to the top and the old generation graph to the bottom
• Improvement: when a time range is selected in a graph or in the threads view, its duration is shown in addition to its time bounds
• Improvement: Threads view: copy to clipboard action copies the selected thread's name
• Improvement: more graph scale gradations available
• Bug fixed: exceptions tree collapsed on each update

Probes

• New feature: added built-in probe com.yourkit.probes.builtin.JUnitTests to monitor execution of JUnit tests.
• New feature: added annotations to identify instrumented method: @ClassRef, @MethodName, @MethodSignature, @MethodParameterTypes. They may be useful when the probe pattern contains wildcards.
• New feature: ability to apply probe to classes and/or methods with particular annotation, e.g. @MethodPattern("*:@org.junit.Test *()") - all JUnit tests; @MethodPattern("@Foo com.bar.* : toString()") - all toString methods in classes in package com.bar annotated with @Foo. See method pattern for detail.
• built-in probe com.yourkit.probes.builtin.AWTEvents: detection of problematic invokeLater() and invokeAndWait() calls has been streamlined by logging the class of InvocationEvent's Runnable

• Probes: improvement: added special column kind com.yourkit.probes.ClassNameColumn to store class names. It is similar to com.yourkit.probes.StringColumn because it also stores strings, but its values will be specially presented in UI:

  • automatic deobfuscation will restore the original class names if the profiled application was obfuscated
  • clicking the class name will open the class in your IDE
• Improvement: @This can be used in onEnter() when instrumenting constructors. Read more...
• Improvement: to apply probe to a constructor, the method name in the probe's pattern should be specified as "<init>", instead of the short class name as it was in versions 9.x. This approach allows monitoring constructors of several classes with a single probe (e.g. of classes with same base class or from same package etc.). Caveat: the old way to specify a constructor in the pattern no longer works. If you have custom probes affected with this change, please correct them accordingly.
• UI: improvement: there are two variants of CPU usage estimation action in the probe UI: "Estimate CPU Usage (Respecting Threads)" accounts samples in appropriate threads only, "Estimate CPU Usage (In All Threads)" accounts samples in all threads matching the time range of the events. Previous version provided only the second behavior.
• UI: improvement: "Detail" column in Timeline: if there is no meaningful description of a particular dependent table row available, the description of corresponding master table row will be shown. For example, corresponding SQL statement will be shown for a prepared statement query.
• Improvement: "Anonymous threads" inspection now also detects threads with name pool-<number>-thread-<number>. It is the name for threads created by the default thread factory of java.concurrent.
• Improvement: "Anonymous threads" inspection results are grouped by thread creation stack trace
• Improvement: "Threads with non-unique names" inspection results are grouped by thread creation stack trace
• Bug fixed: built-in probe com.yourkit.probes.builtin.Servlets might work improperly in some classloader configurations
• Bug fixed: possible exception after re-defining probes in IBM Java

IDE Integration

• Eclipse: new feature: added ability to start J2EE server with the profiler from within the Servers tab in Eclipse.

  

  When you use the profile button first time after installing the profiler plugin, Eclipse may ask to choose the launcher:

  

  To explicitly choose the launcher, use Window | Preferences in the main menu, then go to Server -> Profilers:

  

  Profiler settings will be shown each time when you start the server:

  
• Eclipse: new feature: run configuration "J2EE Preview" supported
• Eclipse 3.7: server profiling supported
• Eclipse: added ability to profile configurations created via GlassFish Server Tools plugin. Note: due to a bug in GlassFish Server Tools, it requires that TPTP is installed.
• Eclipse: improvement: optimized plugin JAR layout
• MyEclipse: plugin improvements and bug fixes
• NetBeans 7.0 supported. The oldest supported NetBeans version is now 6.7.1.
• JDeveloper 11.1.2 supported
• JDeveloper: bug fixed: "Open Declaration in IDE Editor" action might not work

User Interface

• New feature: added popup menu item "Fully Expand Node" in call tree and back traces views

• Improvement: added ability to explicitly specify file name when capturing a snapshot

  
• Improvement: snapshot renamed from within "Open Snapshot" dialog will not disappear from the list of recently opened snapshots

• Improvement: added ability to specify startup options in attach mode by using popup menu item:

  

  Also, the startup options can be specified when attaching by PID.

• Improved logic of own-value columns (own time in CPU view; own count and size in object allocation and garbage collection views).

  The filter settings are taken into consideration: own value for some method call is now calculated as its aggregate value minus the value of only shown subcalls.

  As the result, views like method list much better present results for library methods (usually filtered) which delegate to other library methods. Now, calls to library methods from your application's code will get non-zero own values thus making sorting by own value column a very useful tool.

  Also, this change makes own time in CPU sampling results more coherent with CPU tracing results of same application.

• Improvement: ensured consistency of results shown in different views for filtered methods which are called from both other filtered methods and from non-filtered methods.

  Example: a core library method HashMap.put() was invoked 5 times in total; 3 times it was invoked directly from your application's code and 2 times indirectly from other library methods. Method list view would previously show 3 calls only, while merged call tree - all the 5 calls. Now, the method list also shows all the 5 calls.

• Improvement: if there are several snapshots captured in background, the notification popup window will be shown for the latest snapshot only. This prevents UI clutter with multiple notification windows if the periodical snapshot capture trigger is activated with small period and/or the profiled application has been running for a long time and thus many such snapshots have been captured.
• Improvement: Summary tab better fits low resolution displays
• Improvement: if a menu item has additional description, it is shown as a tooltip. The status bar where it was previously shown is removed to save vertical space which is important on low resolution displays.
• Improvement: to customize the number of levels automatically expanded in trees when clicking [+] or using arrow key, specify -Dyjp.levels.to.expand=number in <Profiler Installation Directory>/bin/yjp.ini.
• Improvement: performance of trees has been slightly improved
• Bug fixed: closing windows with ESC key might not work under certain conditions
• Bug fixed: error dialog was shown if there were more than 100 locally running applications detected
• Bug fixed: tooltips might stay shown for a long time even after mouse exited corresponding components
• Bug fixed: merged call tree might not be fully shown depending on applied filters
• Bug fixed: Mac OS X: text in selected rows in some table columns had color almost indistinctive from the background
• Bug fixed: Mac OS X: progress and other popup window repaint issues

Miscellaneous

• New feature: added AIX support. Running profiled applications and/or the profiler UI is now supported on AIX. Both 32-bit (ppc) and 64-bit (ppc64) JVMs are supported.
• Linux: added support of Linux kernel 3.x, which is necessary to properly detect available system capabilities

• New feature: advanced transfer of remote snapshots

  Added ability to transfer each and every snapshot of the remote application from the remote machine to your local machine, in order to perform their analysis.

  Previously it was only possible to transfer a memory snapshot immediately after it has been captured from the profiler UI, or the latest snapshot captured with a trigger.

  Now it is possible to transfer all snapshots captured with a trigger instead of only the latest one, as well as snapshots captured using the profiler API or the command line tool. Also, you can transfer memory snapshots which you did not immediately transfer after you captured them.

  How it works

  When the profiler is connected to a remote application, click corresponding toolbar button:

  

  If there the remote snapshots missing on your local machine, it will be offered to transfer them:

  

  Option to transfer remote snapshots of other applications

  By default, you can transfer only snapshots of the remote application instance(s) to which you have connected. It's for security: a remote agent provides access to data of its process only.

  However, it may be useful to access a broader range of snapshots sometimes, especially in development and testing. For example, you may need snapshots of previous runs of your profiled application, or even snapshots of other applications stored in the same snapshot directory.

  To achieve this goal, instruct the remote profiled application to store its snapshots in a public snapshot directory.

  A snapshot directory is considered public if its last path segment is named Public or public

  A remote agent to which you have connected allows to transfer:

  • snapshots from its snapshot directory: all snapshots if the directory is public, otherwise only the snapshots which the agent has created

  • snapshots from its per-user configured public snapshot directory (if it differs from the agent's snapshot directory):

    • if a default snapshot directory <user home>/Snapshots is used, the public snapshot directory will be <user home>/Snapshots/Public

    • if a custom snapshot directory is specified in <user home>/.yjp/config/.snapshotdir, its subdirectory named Public will be the public snapshot directory; if the custom snapshot directory last path segment is already Public or public, the snapshot directory will also be the public snapshot directory

    Examples:

    Snapshot Directory	Public Snapshot Directory
    /home/john/Snapshots	/home/john/Snapshots/Public
    /home/james/foo	/home/james/foo/Public
    /home/paul/bar/Public	/home/paul/bar/Public

  If you want a particular application to store its snapshots in the per-user public snapshot directory, use startup option dir=public

  If you want all profiled applications running under particular user to store their snapshots in the public snapshot directory, specify custom snapshot directory with path ending with Public as shown above. Note that individual applications may override their snapshot directory using startup option dir.

• Improvement: simplified profiling of applications running inside an OSGi container: there is no need to manually tweak OSGi settings anymore to allow loading of the profiler classes in attach mode. In particular, this affects attaching to GlassFish 3.
• Java 7: added support of class files with target -7 constant pool entries CONSTANT_InvokeDynamic, CONSTANT_MethodType, and CONSTANT_MethodHandle
• Improvement: filters: added ability to include or exclude not only entire classes or packages, but also particular methods. Read more...
• API: caveat: methods Controller.setPeriodicSnapshotTrigger(int periodSec) and Controller.getPeriodicSnapshotTrigger() have been removed. Use triggers instead.
• Agent: improved reliability: if profiled application contains a broken class file, the bytecode instrumenter will not fail by assertion. Instead, it will write the error to the agent log file and let the JVM normally handle the problem by throwing the class verification error
• Agent: bytecode instrumentation: improved handling of StackMapTable attribute
• Agent: bytecode instrumentation improvements
• Agent: optimization: native methods from JVM internal class sun.misc.Unsafe are not wrapped for instrumentation, to avoid overhead in applications actively using them
• Agent: improvement: J2EE high-level profiling is now implemented using the probe's bytecode instrumentation engine. This reduces bytecode instrumentation overhead, as well as makes the profiler agent code more maintainable.
• Agent: bug fixed: if multiple profiled applications were started one by one with little pause in between they might fail starting due to a non-synchronous read/write access to the temporary JAR file with the agent classes
• IBM Java: problem solved: wrapping native methods of java.security.SecurityManager for CPU tracing might produce incorrect class context
• Export: new feature: added ability to export in XML format
  
• Export: improvement: export to CSV generates "Level" column when exporting trees