Forum Stats

  • 3,873,621 Users
  • 2,266,619 Discussions


Is it possible with JMC 6 to have a size-based allocation profiling like the one from JMC 5 ?

Anthony MAIRE
Anthony MAIRE Member Posts: 6
edited Apr 10, 2018 10:50AM in Java Mission Control


I'm working as a performance engineer for an editor, and JMC is a very valuable tool for us. A key feature we use a lot is allocation profiling since reducing the allocation rate has often a good impact on the overall application performance.

We are currently starting to use Java 9, so we need to use JMC 6 to run a JFR instead of JMC 5.5.

After struggling with the new interface, I succeed to use it to do nearly everything I used to do before. But unfortunately, the memory profiling in the new version seems VERY inaccurate and barely usable.

As far as I know, in the "Stack Trace" view, we can only use the "Count" attribute, which seems to be the number of stack traces captured at TLAB creation or when allocation outside TLAB.

Since the TLAB size is not constant, it is not at all a valuable information. I open an old flight recording made an a JVM 8 with both version of JFR.

In this recording, 1 class represents 55% of the total allocated bytes, and there are 2 allocation spots for this class :

- the first one in a thread pool which does few allocation

- the second one in another thread pool which is allocating a lot.

I assume that the JVM will allocate bigger TLABs for threads in the first pool

Indeed, according to JMC 5.5, less than 2% of the allocation pressure is located on the first spot (129GB vs 2.5GB)

However, in JMC6, only the "count" is available, and the first allocation spot count for 30% of the events (45K vs 105K)

Let's say that the first spot is easy to optimize whereas the second allocation spot is not.

=> Using JMC6, we might think that optimizing the first spot is a valuable thing , but in reality it will be nearly insignificant

Is there any setting I didn't see that allow JMC 6 to display size-based memory profiling ?

Best Regards,




  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 23, 2018 4:24AM

    I will look into this, hoping that it's just an unclarity in the JMC 6 GUI....

  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 23, 2018 5:52AM

    Unfortunately I can't figure out how to get the same information in JMC 6

    The closest I can come is to:

    1. Set the stacktrace view to "Show as Tree" instead of the default view (I guess you did that already)
    2. 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?

  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 26, 2018 7:56AM

    I opened an enhancement request for this -  (will likely be visible after JMC is made open source)

  • Anthony MAIRE
    Anthony MAIRE Member Posts: 6
    edited Mar 26, 2018 9:55AM

    Hi Klara

    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 ?

  • Hirt-Oracle
    Hirt-Oracle Member Posts: 268
    edited Mar 26, 2018 10:02AM

    Yes, the plan is to open source JMC in time for JDK 11.

    Kind regards,


  • Anthony MAIRE
    Anthony MAIRE Member Posts: 6
    edited Mar 27, 2018 8:42AM

    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

  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 27, 2018 8:48AM

    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.

  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 27, 2018 8:57AM


    (I found this 2017-08-15, which unfortunately was after the JMC 6.0 GA build)

  • Klara Ward, Java Mission Control Dev-Oracle
    edited Mar 27, 2018 9:02AM

    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.

  • Anthony MAIRE
    Anthony MAIRE Member Posts: 6
    edited Mar 27, 2018 9:25AM

    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.

This discussion has been closed.