NMT tags (categories) are one-dimensional, and to my knowledge we never really agreed on the granularity to use. We have highly granular categories like mtObjectMonitor and large categories like mtHeap. This causes confusion and arguments (e.g. https://github.com/openjdk/jdk/pull/7115 or https://github.com/openjdk/jdk/pull/7378). There is no real right or wrong since all objectives are valid.
This could be solved by making it possible to group or nest NMT categories. This can be done very simple or complex, depending on whether we want infinite nesting levels or whether group categories shall be real categories.
A simple and pragmatic approach could be to introduce group categories:
- are not real MEMFLAGS, just groupings to be displayed as a sum, with a name, in NMT reports
- don't allow nesting
This would be technically simple, since its only a display thing and would not affect the NMT backend at all. Ruling out nesting keeps display code simple and easy to read. We could have cross groups (e.g. one MEMFLAG can be part of multiple groups). However it would require agreement on how to use it (but tbh every solution does).
This could be solved by making it possible to group or nest NMT categories. This can be done very simple or complex, depending on whether we want infinite nesting levels or whether group categories shall be real categories.
A simple and pragmatic approach could be to introduce group categories:
- are not real MEMFLAGS, just groupings to be displayed as a sum, with a name, in NMT reports
- don't allow nesting
This would be technically simple, since its only a display thing and would not affect the NMT backend at all. Ruling out nesting keeps display code simple and easy to read. We could have cross groups (e.g. one MEMFLAG can be part of multiple groups). However it would require agreement on how to use it (but tbh every solution does).
- relates to
-
JDK-8280088 NMT: Make mtGCCardSet the subcategory of mtGC
-
- Open
-