Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8251342

Rework JFR metaspace free chunk statistics after JEP 387



    • Enhancement
    • Resolution: Unresolved
    • P4
    • tbd
    • 16
    • hotspot
    • jfr


      JFR metaspace statistics, today, are not optimal. Once JEP397 hits they will be even less so.

      This bug is to track tasks to be done in the JFR area after the JEP387 hits mainline.

      There had been some prior discussions, some offlist, some on jfr-dev:




      1) MetaspaceChunkFreeListSummary is too detailed; continuing to do this kind of reporting after jep387 would mean reporting 26 values, one per chunk level.

      This is vulnerable against implementation changes in metaspace (e.g. increasing number of levels).

      Apart fron that, the "Metaspace Chunk Free List Summary" display in jmc would get even more confusing (Today we have 8 columns, with class/non-class freelist occupation reported independently. With jep387, we would have 26 (!) columns per space type.

      Apart from that, chunk freelists now can contain both reserved and committed space, so just even if we were to report those 26 values they would not be very informative. We would need to report reserved and committed size separately, per chunk level per space type, this would bring up us to 39 values. All that once per class space, once per non-class space. This really would be excessive and also pose all kind of UI problems in jmc.

      2) MetaspaceChunkFreeListSummary (for both class- and non-class) should be reported in sync with the rest of the metaspace statistics; so, we should have just one Metaspace status event, not multiple.

      Therefore, we need to rethink reporting of chunk freelists. If we still want that (is anyone using this info?) we need to do it smarter.

      3) Remove chunkSz and rename blockSz from classloader statistics

      This is a similar problem, in detail described in https://bugs.openjdk.java.net/browse/JDK-8245926. My initial fix proposal had been rejected: https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-May/001477.html. We should rethink this again.


        Issue Links



              Unassigned Unassigned
              stuefe Thomas Stuefe
              0 Vote for this issue
              3 Start watching this issue