Discussions

News: YourKit Java Profiler 5.0 Released

  1. YourKit Java Profiler 5.0 Released (18 messages)

    We are pleased to announce the general availability of YourKit Java Profiler 5.0. YourKit provides "on-demand" profiling capabilities, enabling the profiling only when needed, among many other features.

    Changes in version 5.0 from 4.0:

    New and improved platform support

        * New: 64-bit Java on Windows X64 (AMD64) supported
        * New: 64-bit Java on Linux AMD64 supported
        * New: 64-bit Java on Solaris SPARC supported
        * New: 64-bit Java on Solaris AMD64 supported
        * Mac OS X 10.4 "Tiger" Java 5.0 / JVMTI support
        * Mac OS X: "Aqua" Look and Feel
        * Mac OS X: screen menu bar
        * Mac OS X: adapted keymap
        * Mac OS X: other UI improvements

    Telemetry views

        * This new feature, available when a profiled application runs on Java 5.0 and higher, 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.
        * Telemetry information for some recent time period is remembered inside the profiler agent. This allows to connect to profiled application on demand, being able to discover how the application behaved in the past.
        * Telemetry information can be saved to a file and later re-opened in the profiler UI.

    Memory profiling

        * New feature "Biggest objects" automatically shows the list of objects with biggest retained sizes
        * Ability to automatically capture snapshot on low memory. You can instruct the profiler to capture memory snapshot when used memory reaches specified threshold. The threshold can be set up and later altered during profiled application run time. The default value can be specified in command line ('usedmem' option - see -agentlib:help), or via IDE plugin UI. This feature is supported for Java 1.4 and higher.
        * New action "Memory | View Retained Objects" (Shift-F4). One of use cases for this action: browsing "Biggest objects" for the entire snapshot, you may be interested why some particular object retains memory. Simply select the object in the list, apply the action, and then, in new tab that will be opened, search for "Biggest objects", or browse "Class tree" etc.
        * Scalability improvement: it is possible to work with much bigger memory snapshots
        * Memory profiling (JVMTI only): references from class to its constant pool entries (i.e. string literals)
        * Objects in the finalizer queue are treated as garbage
        * Object allocations are correctly recorded on Java 5.0/6.0 with JVMTI for arrays and objects created via cloning, reflection etc.
        * Allocation profiling: new "Method list" view
        * Allocation profiling: Hot spot lists are more compact and thus more useful, through excluding methods that delegate object creation to other methods. Additionally, the hot spots now include directly called filtered (i.e. library) methods, as well as non-filtered (methods from profiled application).
        * Allocation profiling: Merged callees: own allocations are shown as well
        * Allocation profiling: Merged callees: better handling of recursive methods
        * Allocation profiling: "Go to method by name" feature is back
        * Internal optimization: less memory required to load memory snapshots with allocations

    CPU profiling

        * CPU times results accuracy is increased for the platforms that provide appropriate support for thread time measuring. At the moment these platforms are: Windows NT/2000/XP and Solaris. We're looking forward to use the same approach for the latest Linux kernels, and are investigating whether this approach is possible for Mac OS X.
        * The ability to measure method invocation counts in addition to CPU times is implemented using dynamic bytecode instrumentation approach, that allows to significantly reduce impact on performance of profiled application in comparison with approach used in previous versions of the profiler. This ability is only available in Java 5.0 or higher, because older JVMs do not provide appropriate means for dynamic bytecode instrumentation.
        * New "Method list" view
        * Hot spot lists are more compact and thus more useful, through excluding methods that delegate resource consumption to other methods. Additionally, the hot spots now include directly called filtered (i.e. library) methods, as well as non-filtered (methods from profiled application).
        * Merged callees: own times are shown as well
        * Merged callees: better handling of recursive methods
        * "Go to method by name" feature is back
        * Internal optimization: less memory required to load CPU snapshots

    IDE Integrations

        * 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)
        * "Profile" action by default starts application with CPU times measuring (can be changed from plugin UI)
        * Eclipse 3.1 supported
        * Eclipse: problem fixed: navigation feature didn't work on some project configurations
        * IntelliJ IDEA: plugins are installed into user home, into IDEA's standard config directory.
        * IntelliJ IDEA: if you launch profiling application with Java 5.0, but the Java version cannot be retrieved via IDEA's Open API, you may take advantage of Java 5.0 profiling capabilities, selecting "Force profiling with Java 5.0 API (JVMTI)" checkbox in the "Startup/Connections" tab of a run configuration.
        * NetBeans: Tomcat profiling is now supported via the "Profile" action
        * NetBeans: navigation feature now supports anonymous inner classes
        * JDeveloper: addtional profile options are configured from UI
        * JBuilder: addtional profile options are configured from UI
        * Bug fixes

    J2EE Integrations

        * Sun Java System Application Server (previously named SunONE) 7.x/8.x supported
        * Apache Geronimo supported
        * Special treatment of Tomcat running as Windows service in the integration wizard
        * Oracle Application Server 10g supported
        * JRun: ability to specify target Java version (1.3/1.4 vs 5.0) in the integration wizard
        * JRun server: supported on Mac OS X
        * If integration with J2EE server cannot be performed fully automatically, user is shown an appropriate error message and is instructed how to integrate manually
        * Integration wizard generates scripts that choose appropriate system-dependent agent library in runtime. In particualr this allows to e.g. generate script on Windows for Linux server where running the profiler UI is not possible.

    Other important improvements

        * All locally running profiled applications are correctly detected on all supported platforms.
        * List of applications to connect for each application shows a descriptive name based on main class or jar-file of the application.
        * To distinguish snapshots captured on exit, they are named with prefix based on main class or jar-file of the profiled application.
        * Verbose application name based on main class or jar-file is avalable on Mac OS X as well.
        * User interface options cleanup. On Mac OS X there's no configuration dialog at all, and all settings are retrieved automatically.
        * Connection UI changed
        * Added ability to connect to remote application given host only
        * Java 6.0 "Mustang" supported (tested with b42)
        * UI: "Useful actions" in profiler views
        * Some changes in the profiler API
        * Some changes in the command line parameters of the agent
        * Improved legends
        * Welcome screen that is a good starting point to begin work with profiler
        * An example of Java application can be launched directly from the Welcome screen, that helps to start exploring the profiler with no additional setup
        * Context-related hints give short description and explain purpose of each of the profiling views
        * Improved Help
        * Other UI improvements

    Threaded Messages (18)

  2. Anybody out there who has used YourKit? I'm interested in hearing about anybody's experience with on-demand profiling of large memory spaces.
  3. Hi Eiman,

    I have successfully used it (either 4.0 and 5.0 beta one month ago).

    I didn't had any chance to test on-demand profiling (is IBM involved in your-kit ? ;)

    It's a pretty decent tool, which helped me to test and profile my application, without any problem.

    The price is more than decent as far as I'm concern, compared to other products.

    Eclipse integration is smooth. I didn't had any problem with it (but don't expect to have an eclipse plugin. Eclipse just launch an external yourkit)

    Actually, I would say that it met my needs.
  4. I used it briefly to debug a memory leak. It's non-intrusive enough that I was able to run (the batch appliaction) at near full speed. When I dumped the memory, the heap was about 730 MB. I needed more than GB of RAM to load that into the profiler, but when I found a 4GB box to use, it worked supprisingly well. I found the bug within 10 minutes.
  5. I agree: the biggest strength over JProfiler is the usage of relatively non-itrusive JVMTI profiling API, enabling to run the application nearly at full speed.

    The only drawback is that making a snapshot pauses the execution of the JVM for some time (was ~30sec for my app with approx. half a gigabyte heap size), limiting its use e.g. in production services. Whether this should be done or not, is another matter though ;-)

    Regards,
    Einar
  6. Since version 4.0, JProfiler can also use JVMTI. This will be good when 1.5 becomes more widespread in production environments. It is still largely 1.3 and 1.4 in test/pre-production environments where such tools might even be considered in resolving particular memory/thread related issues.

    I really cannot see operations allowing a memory dump be performed on a production environment unless the dump is exported on a JVM crash which unfortunately would break the JVMTI agent itself.

    JProfiler and Yourkit are a step in the right direction for low level memory/thread analysis on a developer workstation with smaller datasets. Both far exceed OptimizeIt and JProbe in terms of stability and usability.

    Regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  7. Anybody out there who has used YourKit? I'm interested in hearing about anybody's experience with on-demand profiling of large memory spaces.

    I've used a previous (3.1) release a couple of days ago. It seamlessly integrated into my Tomcat 4 (modified the start-script) and started up the server. I clicked my way through my application until I reached the area I wanted to profile. That's when you tell YJP to collect data and when you're finished (i.e. your browser/application has returned from the request) you tell it to stop.
    As a result you get a nice tree of the methods that were called and their execution times. That's what made it pretty easy for me to tune my application and even helped me find and remove a few unnecessary calls.

    The only drawback is, that the 3.1 version I used was VERY slow and a call that usually took 2 minutes to return took 10-15 minutes with YJP's activated data collection. I don't know about 5.0's performance as I didn't get the chance to test it yet.

    Regards,
    Rias
    sherzad.com
  8. Hi All,

    I have just published an Insight article discussing clock time reporting in J*EE production systems as well as the impact of excessive temporary object allocations.

    The article also highlights one of the main differences between a Java profiler and a production application performance management solution.

    (Micro) Benchmarking and Garbage Collection
    http://www.jinspired.com/products/jdbinsight/callstackbenchmark.html

    Regards,

    William Louth
    JXInsight Product Architect
    CTO, JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  9. Hi All,I have just published an Insight article discussing clock time reporting in J*EE production systems as well as the impact of excessive temporary object allocations. The article also highlights one of the main differences between a Java profiler and a production application performance management solution.(Micro) Benchmarking and Garbage Collectionhttp://www.jinspired.com/products/jdbinsight/callstackbenchmark.htmlRegards,William LouthJXInsight Product ArchitectCTO, JInspired"J*EE tuning, testing and tracing with JXInsight"http://www.jinspired.com

    Your demos aren't working:
    http://www.jinspired.com/products/jdbinsight/tour.html
  10. Hi,

    We are updating and consolidating the product tour. The link to the tour has been removed from all pages until we have a nice flash demo highlighting some of the really nice and effective features in JXInsight 4.0.

    Thanks, William
  11. As Eiman Abdelmoneim, I would like to know if someone succesfully used it to analyse memory object allocation (I want to know instance numbers, size and object graph size) with a big J2EE application (lot of objects and ejbs) with large space JVM (ie : 1go).
    Up to now, I haven't find any tool able to do this (I unsuccesfully tried with the previous version of Yourkit), the snapshot taking forever...
  12. Works way better than competition (I also use OptimizeIt and have tried JProbe), mostly because it takes snapshots. The really nasty leaks and performance problems happen only in production. Those that you can reproduce in devel/test are fixed before going live, right?. "On-line" profilers are too intrusive for production (read: slow application down by up to 20 times and/or crash every few hours).

    YourKit doesn't affect the application at all until you start saving the snapshots. Taking a memory snapshot pauses the application while it's dumping the heap. Taking CPU snapshot slows the application a bit, say 5-10%. But after you're done, it's back to normal. I also haven't had a single crash that I could blame on this profiler.

    But it's still hard to figure out exactly which objects are retaining large graphs or which procedures are really slowing the app down. YourKit 4.x has very rudimentary heap / CPU time views. I really miss OptimizeIt's graph displays for memory. I have to try YourKit 5.0, though. It sounds they added a few very usefull views.
  13. Comparison to JProfiler?[ Go to top ]

    Anyone here who has experience with this product and JProfiler? What are the relative strengths/weaknesses of each? How do they stack up against one another?
  14. Comparison to JProfiler?[ Go to top ]

    I had to collect data about a memory leak that happen over several hours of time in the production server. Using JProfiler this was not possible since it 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 instead of JProfiler now.
  15. How does the YourKit Java Profiler compare to the free netbeans profiler.

    Thanks,
    Monickam
  16. Comparison to JProfiler?[ Go to top ]

    I just downloaded eval and started testing it. It does not appear to have "live" cpu profiling which is something I've come to rely on in JProfiler. It always seems to force me to make a "snapshot" in order to profile the CPU stats. This is not really comfortable for the type of application that I'm working with. I think I'll stick with JProfiler for now.
  17. Hi,

    YourKit helped me a lot in debugging difficult memory leaks with class loaders - including some memory leaks in SUN JDK 1.4.
    It was the only decent profiler I've found, that correctly defines GC roots - other profilers did not even show class loaders, and assumed that a static member of a class was GC root!
  18. Some non-YourKit related experience with profiling and debugging J2EE apps:
    I'd say the thing that eases profiling most is having as "static code" as possible. You want your stack traces and class hierarchies to follow business logic as much as possible. This means avoiding reflection, libraries and frameworks which abstract out the code and O/R mappers that defer database accesses. But all these things also have benefits, so you have to "balance the forces".

    An example:
    In one of the (company-internal, custom) frameworks all serialized object graphs are converted into an intermediate, generic object graph on the client - basically consting of only a few classes like Entity and Attribute, held by a few objects with meaningfull class names like Party or PowerTimeline. Reasons? Nulls, partially read objects, better control over network traffic, not trusting reflection... Works rather well, as long as you don't have to figure which 80.000 Entities out of 110.000 are loitering and which are actually needed...
  19. YourKit, JProfiler[ Go to top ]

    They're both decent, and both miles ahead in terms of usability of the older generation (JProbe, OptimizeIt).

    Last I used both, JProfiler still felt more capable and YourKit still felt more nimble. If I had to buy one based on my most recent experience, I'd go with JProfiler, and keep my eye out for YourKit, which is improving rapidly.

    Both have evolved since then, so I can't really speak to the improvements, but I'd certainly recommend trying both of these if you're looking for a Profiler.

    Am also looking forward to trying NetBeans to see how JFluid's coming along.