I will look into this, hoping that it's just an unclarity in the JMC 6 GUI....
Unfortunately I can't figure out how to get the same information in JMC 6
The closest I can come is to:
- Set the stacktrace view to "Show as Tree" instead of the default view (I guess you did that already)
- Filter the Memory page on Top Method or Full Stacktrace, for all the the different stacktraces you are interested in, and check how much that code location actually allocates. Quite impractical, but if you only have a few and really want to know before you start fixing your code it might be useful.
The Pressure column feature is missing from JMC 6 mainly because we chose to break out the stacktraces to a separate view. I believe we prepared for having different values than count in the second column, but never got around to implementing any. (There's an opportunity for anyone wanting to be involved when JMC is open sourced later this year...)
It's also in part caused by the fact that we tried to combine the "In new TLAB" and "Outside TLAB" events, and thus we might be missing some of the more detailed statistics that only concern one of the events. It is possible to view only the "In TLAB" events in the Memory page if you would want that, just go to the Event Browser, select the event type you want, do Store Selection, then go to the Memory page and use that selection in the dropdowns on the top of the page.
I guess you already found the JVM Internals/TLAB Allocations page, where the allocations are grouped by thread instead of class. Did that help at all in your case?
Thank you for the quick answer and for the enhancement request, although "enhancement" is a quite strange qualification for restoring a feature that was working fine in previous version
The filtering workaround may works in this very simple case (which was a profiling of one core component but not the whole software which is far more complex)
On complex application, we may not have 1 class that dominate the allocation profile that much. Basically what I commonly need is the "Allocation Profile" view from JMC 5.5
In that case the workaround is even more painful : for the filtered stack trace, it will contains total allocation for all classes in a particular branch of the tree, but there is not the total allocation for the tree, I need to sum up the figures from each class manually
For the TLAB view, knowing the top allocation thread is clearly a nice information. However, since we are using thread pools (i.e j.u.c.ExecutorService) of different size, it is still far from perfect.
Any idea of when JMC will be made open source ? Will it be for the release of Java 11 ?
Yes, the plan is to open source JMC in time for JDK 11.
Hello Klara & Marcus
I tried to use a fixed TLAB size (adding -XX:TLABSize=65536 -XX:-ResizeTLAB to the command line) so that the "count" in the stack view can be a valuable information.
However I experienced some weird bugs :
- There are several entries for the same class in the "Memory" page, for both JDK and custom classes
- Some stacks are not grouped properly, When selecting only the top allocated classes (indeed, the entry with the biggest total allocation in the class view, since there are 2 entries for this class), I had this stack view with the "show as tree" mode
- This grouping issue is not deterministic, when selecting random entries in the class table and selecting the top entry another time (without changing any setting), it can show different results (both in the location of the duplication and in the number of event counted for the duplicated stack traces)
I tried to analyze 3 JFR in JMC 6.0:
- the one presented here was made by JMC 6.0, profiling a JVM using JDK 9.0.4, with additional JVM arguments to have fixed TLAB size
- a second one was made using the same setup (JMC 6 / JDK 9.0.4) without additional TLAB flags => same bugs
- the third one was made using JMC 5.5, profiling JDK 1.8.0_144 => no duplication issue
That's pretty sad : JMC 5 used to be a very good profiling tool, but currently JMC 6 is just not working
I recognize this issue, with the same class duplicated, if I remember correctly, a workaround is to switch from the Memory page and back again. I will try to locate a bug I opened, or file a new one.
You are correct in that we use different parsers for JDK 8 recordings and JDK 9 recordings. It could be that the classes have different underlying id:s in the different binary chunks that the recording consists of, and that is why they are different. Why they are "merged" after a switch back and forth to the Memory page is unclear, but I will investigate.
As you have noticed, we rewrote the GUI from scratch in JMC 6, and it has not yet had time to "mature" the way the JMC 5 GUI had,
I'm terribly sorry it's causing you, and I assume other users as well, these kinds of trouble.
Do you get the weird behavior in the stack trace view after switching from the Memory page and back?
I could reproduce it when I selected two "char" lines in the Memory table, but not after reloading the page.
Thank you for the quick answers, this is really appreciated
My JFR file is pretty big (125 MB), maybe this is an important detail.
After switching pages a few time, I finally have no more duplicates in the class table.
Once this happen, reloading the memory page several times does not lead to another duplication in that table
Before the stabilization, I saw several distribution between the 2 entries in the class table.
However, the Stack Trace view still have the issue, even after the stabilization of the Class table.
Interesting (or horrible) that it took you several reloads of the page to get rid of all duplication.
I can't reproduce the issue with multiple classes with our main branch, will check if I can still see the stack trace issue...
The stack trace duplication I saw disappeared after I changed "Distinguish Frames By" to "Class" and then back to "Method". Does not feel very reliable I'm afraid.
Unfortunately, your feeling is right and It's definitively not reliable : it does not work on my JFR
Any update on this subject ?
On our side, since it seems pretty hard to have a GA version of JMC where allocation profiling works correctly before several months, we developed a little parser based on this article from Marcus : JMC 6 Automated Analysis Headless – Marcus Hirt
It converts a JFR file in the input format required by flame graphs ( https://github.com/brendangregg/FlameGraph ) so that we can have a visual representation of the allocations (and with the --reverse parameter in the FG script, we can either have the equivalent of the "Allocation By Class" and the "Allocation Profile" features from JMC 5)
It is not as practical as using JMC 5, but it can do the job pretty well until JMC 6 UI is fixed.
I hope that this trick can help users which have similar issues than us, and I will be pleased to test the next JMC version if it includes the bug fixes we need.