Java HotSpot Virtual Machine

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