About the Early Access Program

YourKit Early Access Program (EAP) is the easiest way to get in touch with the latest technologies from YourKit. You can have early access to new products and internal builds.

NOTE: THIS IS PREVIEW SOFTWARE AIMED AT PROVIDING YOU WITH AN OPPORTUNITY TO TEST THE NEWEST FEATURES SCHEDULED FOR THE NEXT MAJOR RELEASE. YOURKIT DOES NOT GUARANTEE THAT THIS SOFTWARE WILL RUN TROUBLE-FREE. USING THIS SOFTWARE IS AT YOUR OWN DISCRETION AND DOES NOT ENTITLE YOU TO ANY CUSTOMER SUPPORT.

Feedback

Your comments, suggestions and bug reports are welcome. In the forum you can discuss product features with YourKit developers and post bug reports.


Download YourKit Java Profiler 2013 EAP, build 13012 (June 18, 2013)

Version 2013 will be the next release of YourKit Java Profiler. See change list.

You don't need a license key to use EAP build. Just install the build and use it.

Windows (x86, x64) Download and run installer

Mac OS X (Intel)

Use Mountain Lion (10.8)? Read this first!

Download and unpack one of the following zipped applications:

Linux (x86, x64, ARM, ppc, ppc64) Download tar.bz2 archive
Unpack: tar xfj <archive name>.tar.bz2
Launch bin/yjp.sh

Solaris (SPARC, x86, x64) Download and unpack ZIP archive
Launch bin/yjp.sh
HP-UX (IA64, 32- and 64-bit)
AIX (ppc, ppc64)
FreeBSD (x86, x64)

Actually, the ZIP archive is all-in-one: it contains files for all supported platforms, including Windows, Mac OS X, and Linux. However, to ensure easiest installation and best user experience, it is strongly recommended to use a dedicated download option for these platforms instead: Windows bundle provides convenient installer and bundled JRE, Mac OS X - a Mac-style application, Linux - bundled Oracle JRE for x86/x64 which is superior to OpenJDK when it runs UI applications.


Changes in builds 13012

Changes in builds 13010

  • Memory profiling: merged paths: improvement: "<Retained from several objects simultaneously (don't have a dominator)>" entry expands to all shortest non-intersecting paths from GC roots
  • Memory profiling: merged paths: usability improvement: entries whose only child was "<Objects are GC roots>" are now leafs
  • Memory profiling: bug fixed: "Non-serializable objects referenced from Serializable" inspection didn't properly treat LinkedList in newest Java versions
  • CPU profiling: J2EE high-level profiling: overhead reduced
  • CPU profiling: CPU tracing: a new startup option _instrument_all_methods has been added to instrument primitive getters, setters and other similar short methods which only access object fields and/or return a value. By default, such methods are not instrumented to reduce overhead. Use this option when invocation counts for all called methods are more valuable than the time accuracy and lower overhead.
  • CPU profiling: CPU tracing: UI: added ability to show methods that took less than 1 ms by specifying -Dyjp.show.shortest.methods=true in <Profiler Installation Directory>/bin/yjp.ini
  • API: deprecated members of com.yourkit.api.Controller have been removed
  • API: deprecated class com.yourkit.api.ProfilingModes has been removed; use corresponding constants in com.yourkit.api.Controller instead

Changes in builds 13008

  • Probes: improved ability to dynamically activate and deactivate probes in runtime. The change simplifies configuration, because now you don't have to decide which probes to enable on startup, but make the decision later on demand. This also helps to reduce the overhead of the probes when they are not needed.

    Previously, it was also possible to register or unregister probes in runtime by re-instrumenting bytecode of all target classes. The problem of this approach is the JVM class reloading latency: JVM keeps executing an old bytecode definition for already loaded objects even after a profiling agent has supplied a new definition. Runtime probe switching wouldn't work for such objects. In particular, this affected many of the built-in probes. Also, reloading of multiple classes might take a lot of time.

    Now, probe target classes are permanently instrumented with the probe callbacks, which behave depending on the probe state:

    • On: the callbacks are active and do their job.

    • Off: the callbacks are empty and do nothing. The effect is the same as if the probe was not registered at all. The probe overhead in this state is almost negligible.

    • Auto: the probe is active only while CPU profiling is running: the probe automatically turns On when CPU profiling starts and then automatically turns Off when CPU profiling stops. This state is intended for the probes whose results are naturally associated with CPU profiling session, and/or would impose undesirable overhead when no profiling is being performed.

    The following table shows the default states for the built-in probes:

    Built-in probe
    Default state
    com.yourkit.probes.builtin.Threads On
    com.yourkit.probes.builtin.Processes On
    Class loading On
    com.yourkit.probes.builtin.FileStreams Auto
    com.yourkit.probes.builtin.FileChannels Auto
    com.yourkit.probes.builtin.RandomAccessFiles Auto
    com.yourkit.probes.builtin.Sockets Auto
    com.yourkit.probes.builtin.Databases Auto
    com.yourkit.probes.builtin.Servlets Auto
    com.yourkit.probes.builtin.JUnitTests On
    com.yourkit.probes.builtin.AWTEvents On

    The default state for user-defined probes is On.

    New startup options have been added to control the initial state. They work for both built-in and user-defined probes.

    Startup option
    Description
    probe_on=<full qualified probe class name or pattern>

    Set state of matching probes to On.

    Initially, the list of probes to be registered consists of the built-in probes in their default state, either On or Auto.

    If the specified full qualified name is a pattern, i.e. contains * as a wildcard, the state of all matching probes to be registered will be changed to On.

    If a full qualified name without the wildcard is specified, the probe will be added to the list of probes to be registered, and its initial state will be On.

    You can later change the probe state in UI or using the API.

    probe_off=<full qualified probe class name or pattern>

    Set state of matching probes to Off.

    Initially, the list of probes to be registered consists of the built-in probes in their default state, either On or Auto.

    If the specified full qualified name is a pattern, i.e. contains * as a wildcard, the state of all matching probes to be registered will be changed to Off.

    If a full qualified name without the wildcard is specified, the probe will be added to the list of probes to be registered, and its initial state will be Off.

    You can later change the probe state in UI or using the API.

    probe_auto=<full qualified probe class name or pattern>

    Set state of matching probes to Auto.

    Initially, the list of probes to be registered consists of the built-in probes in their default state, either On or Auto.

    If the specified full qualified name is a pattern, i.e. contains * as a wildcard, the state of all matching probes to be registered will be changed to Auto.

    If a full qualified name without the wildcard is specified, the probe will be added to the list of probes to be registered, and its initial state will be Auto.

    You can later change the probe state in UI or using the API.

    probe_disable=<full qualified probe class name or pattern>

    Matching probes will not be registered on startup.

    This option totally eliminates the matching probes. No classes will be instrumented with their callbacks.

    You can't later change the probe state in UI. You can use the API to register the probe, but instead its recommended to use the option probe_off and activate the probe on demand by changing its state to On or Auto.

    Examples:

    probe_on=*

    All (built-in) probes are On. This was the default behavior in the previous versions.

    probe_off=com.yourkit.probes.builtin.Databases

    A short form is available for built-in probes: use a dot instead of the package name com.yourkit.probes.builtin:

    probe_off=.Databases

    Databases probe will be Off. Other probes will be in their default state.

    probe_disable=*,probe_on=com.foo.Bar

    Disable all built-in probe and register a user-defined probe class com.foo.Bar, whose initial state is On.

    probe_auto=com.foo.Bar

    Register a user-defined probe class com.foo.Bar, whose initial state is Auto. The built-in probes will be in their default state.

  • Memory profiling: merged paths: improvement: separate nodes are used for GC roots and objects retained from multiple objects
  • CPU profiling: UI: optimization: Hot Spots view opens much faster
  • IDE integration: Eclipse: bug fixed: the plugin might not install

Changes in builds 13006

  • CPU profiling: snapshot comparison: improvement: slave views "Back traces", "Callees list" and "Merged Callees" are available for a method selected in the "Method list". They are especially useful when analysing a method called from different places in the snapshots being compared.

  • Triggers: new macro &{CURRENT_THREAD_NAME} is available in PrintMessage actions in triggers on method invocation

Changes in builds 13004

  • New feature: performance charts.

    The performance charts graphically present high level statistics for EE and SE applications, such as:

    • JSP/Servlet requests:
      • count, per second
      • request duration (average, max)
    • Database connections:
      • how many opened and closed, per second
      • live time (average, max)
    • Database queries:
      • count, per second
      • call duration (average, max)
    • Sockets:
      • how many connections opened with accept() or connect() and how many closed, per second
      • for how long connections stayed open (average, max)
      • bytes read from sockets, per second
      • bytes written to sockets, per second
    • File I/O (includes FileInputStream, FileOutputStream, RandomAccessFile):
      • how many files opened and closed, per second
      • for how long files stayed open (average, max)
      • bytes read from files, per second
      • bytes written to files, per second
  • Memory profiling: UI: object explorer: values are immediately shown for objects of the following classes:

    • primitive value wrappers:
      • java.lang.Integer
      • java.lang.Long
      • java.lang.Short
      • java.lang.Boolean
      • java.lang.Byte
      • java.lang.Character
      • java.lang.Double
      • java.lang.Float
    • java.util.Date
    • java.net.URL
    • java.io.File
    • java.util.zip.ZipFile
    • java.util.jar.JarFile
    • atomics:
      • java.util.concurrent.atomic.AtomicInteger
      • java.util.concurrent.atomic.AtomicLong
      • java.util.concurrent.atomic.AtomicBoolean
  • Memory profiling: UI: object explorer: self referencing objects are explicitly indicated with [Self reference], and corresponding tree nodes are leafs now to avoid infinite expansion
  • Memory profiling: UI: object explorer: added ability to customize the maximum number of shown individual objects with the help of the property -Dyjp.max.objects.to.show=number in <Profiler Installation Directory>/bin/yjp.ini. The default value remains 500. Note: setting bigger values increases memory usage and can slow down the UI.
  • Memory profiling: bug fixed: some HPROF snapshots with huge arrays (> 2 GB shallow size each) were reported invalid and would not open
  • Memory usage telemetry: the view layout has been improved to give the graphs more space
  • Probes: UI: columns with event specific data, such as file name or SQL statement, are placed before other columns to avoid horizontal scrolling
  • CPU profiling: added ability to disable the zero-time method correction with the help of the property -Dyjp.zero.time.methods=false in <Profiler Installation Directory>/bin/yjp.ini. The zero-time correction means that any calls to the following methods are ignored:
    java.lang.Object : wait(*)
    java.lang.Thread : sleep(*)
    java.lang.Thread : yield(*)
    java.net.PlainSocketImpl : socketAccept(*)
    java.net.PlainSocketImpl : accept(*)
    java.net.ServerSocket : accept()
    org.apache.tomcat.jni.Socket : accept(*)
    sun.nio.ch.ServerSocketChannelImpl : accept0(*)
    sun.misc.Unsafe : park(*)
    java.util.concurrent.locks.LockSupport : park*(*)
    com.ibm.tools.attach.javaSE.IPC : waitSemaphore(*)
    sun.nio.ch.EPollArrayWrapper : epollWait(*)
    
    Technically, their time is subtracted from the caller time up to the call tree root when CPU profiling results are loaded in UI. In other words, their time is always assumed to be 0 when the correction is applied.
  • Probes: problem solved: built-in probes might not work with some security manager settings
  • Probes: performance of built-in probes has been slightly improved
  • UI: Threads view: added ability to change the default thread show mode from "All Threads" to "Live Threads Only" by specifying -Dthreads.default.live_only=true in <Profiler Installation Directory>/bin/yjp.ini.
  • UI: Threads view: added ability to choose "Show selected thread only" by default by specifying -Dthreads.default.selected_only=true in <Profiler Installation Directory>/bin/yjp.ini.
  • UI: Threads view: added ability to change the default stack trace presentation mode from "Filtered stacks" to "Full stacks" by specifying -Dthreads.default.full_stacks=true in <Profiler Installation Directory>/bin/yjp.ini.
  • UI: list of locally running applications: attached agents and agents loaded on start are explicitly indicated as "Agent attached" and "Agent loaded on start" respectively
  • IDE integration: Eclipse: added missing "Profile As" popup menu items for Google plugin and Maven
  • IDE integration: NetBeans: added support of Enterprise Application Client projects

WHAT'S NEW
 
May 21, 2013
YourKit Java Profiler 2013 Early Access Program (EAP) started Read more »
December 10, 2012
YourKit Profiler 8 for .NET released Read more »
AWARDS
JDJ Editors' Choice Award Winner YourKit Java Profiler received the Java Developer's Journal Editors' Choice Award.
"I had to collect data about a memory leak that happen over several hours of time in the production server. Using other profilers this was not possible since they kept on crashing. Using YourKit this was amazingly easy. It just ran in the background and I gathered statistics at certain moments in time and then compared them against each-other. YourKit is a really nice profiler and I use it now."
Geert Bevin,
Lead developer of RIFE
web application framework