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:

https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-May/001476.html

https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-May/001477.html

Problems:

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.