Forum Stats

  • 3,875,076 Users
  • 2,266,801 Discussions
  • 7,912,074 Comments

Discussions

Using jmc/jfr as a profiler

Jonathan Ross
Jonathan Ross Member Posts: 12
edited Oct 13, 2016 4:45PM in Java Mission Control

Hi Marcus et. al.,

I have a couple of queries regarding the code/thread views in JMC 5.5 (M5.5.0-108, 165303), and how to effectively use working sets when analyzing the data.  (I am aware that everything is better in 6 ... for now I'm stuck with 5.5.)

  1. Often, when looking at a call tree view, stack frames start with '~Unclassifiable~ ()', and others are orphaned (and not the run() method of of a thread).  What does this mean? How is it possible for the JDK to not know the full stack frame?
  2. In the FAQ, I read how to turn of only taking samples at safe points.  Other than eliminating safe point biases, how do you expect -XX:DebugNonSafepoints will affect profiling?  Will enabling it affect the performance of the JVM?
  3. Is there a way to view only the stack-frames from the operative set in the various code views (hot methods/call tree/callers/callees)?
  4. ...How do I use the call tree search bar?  It appears to use some form of globbing, but it only matches roots of stack frames.  Is it possible to search branches of the call tree?

Feature requests/bug reports (a couple of which I have discussed in person with you):

  1. Please include call frames where we are in native methods in the data!  Not doing so makes it very hard to do a proper triage regarding performance bottlenecks.
  2. Other profilers provide a way to focus on a particular method, presenting that as the root stack-frame in a new tree view. I find this an essential technique to pinpoint performance bottlenecks in systems with functional/recursive calling patterns (e.g. ForkJoin, etc. etc.). Could this be added to 6 please?
  3. Please add a 'callees' tree view under the 'Hot Methods' view.
  4. My favorite profiler ever, Apple's Shark, allowed one to "attribute method to caller". I would love to see this in a modern Java profiler. This is particularly useful in bottom-up ("hot methods") analysis: attributing multiple related library calls (e.g. every single method of java.util.HashMap) to the callers makes algorithmic bottlenecks more readily apparent than if one has to crawl through the trees of java.util.HashMap.getNode, putVal, resize, get, and all the equals and hashCode methods individually. (The callees view from the previous point would also be super-useful here.)
  5. If I expand a tree view, go to a different tab or page and go back, the tree view is collapsed again. (This is a serious usability issue imho.)
  6. Invariably, after using the code views on a large flight recording for some time, JMC freezes on me. Memory leak?

Thanks in advance,

Jonathan

Jonathan RossHirt-Oracle

Best Answer

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 3:08PM Answer ✓
    1. The thread can be sampled outside of a safe point, for which no metadata has been generated. Start with the flag to output metadata for outside of safepoints. See Improving the Fidelity of the JFR Method Profiler – Marcus Hirt
    2. In most cases the impact should be little more than slightly more memory used for generated code. As with all profiling, measure the impact for your particular setup.
    3. Yep. Just add stuff to the operative set and go to the Events/Stack Trace view.
    4. Don't think so. I'll make a note of checking this out later. Last day before vacation, and lots to do.

    Thanks for the great feature requests! It's sad you guys won't be able to join the commercial EA.

    Jonathan RossJonathan Ross
«1

Answers

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 3:08PM Answer ✓
    1. The thread can be sampled outside of a safe point, for which no metadata has been generated. Start with the flag to output metadata for outside of safepoints. See Improving the Fidelity of the JFR Method Profiler – Marcus Hirt
    2. In most cases the impact should be little more than slightly more memory used for generated code. As with all profiling, measure the impact for your particular setup.
    3. Yep. Just add stuff to the operative set and go to the Events/Stack Trace view.
    4. Don't think so. I'll make a note of checking this out later. Last day before vacation, and lots to do.

    Thanks for the great feature requests! It's sad you guys won't be able to join the commercial EA.

    Jonathan RossJonathan Ross
  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 12:48PM

    Which platform are you running JMC on?

  • Erik - Hotspot Engineer-Oracle
    edited Oct 12, 2016 1:55PM

    Hi Jonathan,

    Thanks for great feedback. I work on the JVM side of Flight Recorder. Some comments on the feature requests.

    "How is it possible for the JDK to not know the full stack frame?"

    The problem is that we have a limit at 64 frames. If there are more frames the stack trace is truncated, which means the root frame is unknown and the 64:th frame can't be used to build the call tree. You can change the stack depth with -XX:FlightRecorderOptions=stackdepth=<frame-count>, but beware that the overhead can be considerable and the application may halt completely because the JVM needs to write large amount of stack trace data. I don't recommend that you change this option, especially in a production environment, but at least now you know why it happens.

    "Please include call frames where we are in native methods in the data!"

    We are aware of this problem and it's on our backlog.

    "Please add a 'callees' tree view under the 'Hot Methods' view."

    Yeah, I liked that view too in JMC 4.x. Marcus?

    Thanks

    Erik

    Jonathan RossJonathan RossHirt-Oracle
  • Jonathan Ross
    Jonathan Ross Member Posts: 12
    edited Oct 12, 2016 5:17PM

    MacOS Sierra (10.12 16A323).

  • Jonathan Ross
    Jonathan Ross Member Posts: 12
    edited Oct 12, 2016 5:32PM

    Interesting to learn about the stack-depth and how to change it, thanks for that! As I am not allowed to use this in production, I guess I can experiment with increasing the frame count in my dev jmh benchmarks.  When you say

    the JVM needs to write large amount of stack trace data

    do you mean to say that this is only an issue when it writes the flight recording to disk?  If so, why is this an issue?  Trees are quite compressible, no?

    I suppose this makes my 2nd request more appealing than I thought.  Oftentimes these deep stack frames come from framework code and recursion.  Focussing on a particular method (that is relatively close to all leaf nodes) will allow one to group together the relevant branches, whether they are orphaned or not.

  • Jonathan Ross
    Jonathan Ross Member Posts: 12
    edited Oct 12, 2016 6:18PM
    Hirt-Oracle wrote:    3. Yep. Just add stuff to the operative set and go to the Events/Stack Trace view.

    Okay, I just verified that this works (and remembered you demoing this ... sorry!). Through trial and error I discovered that I had to select 'Java Virtual Machine -> Profiling' events to get the same data set as under the other tabs. I think I've got the hang of this now....  It would still be very nice to add the same functionality directly to the Code/Threads tabs.

    Oh yeah, and please make all (tree-) tables searchable...

    Hirt-Oracle
  • Jonathan Ross
    Jonathan Ross Member Posts: 12
    edited Oct 12, 2016 6:20PM

    One more thing.... is it possible to look at a top-down call tree in the Events tab?  It only appears to do bottom-up?

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 8:16PM

    The trees are, as you say, highly compressible. As a matter of fact, they are stored as an index into the constant pool in the recording. The main reason to avoid deeper traces is that it takes a longer time to capture them.

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 7:42PM

    Will have to contemplate how to get a workable callees tree view in the New World Order. Will definitely not happen in time for 6.0.0.

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Oct 12, 2016 7:43PM

    A split view for the new StackTrace view would be nice. You activate the callees view, and you get a callees view to the right of the normal stack trace view.  Then you can enable it when you need it, and not have to use the screen estate for it, when you don't.

This discussion has been closed.