RFR: JDK-8281460: Let ObjectMonitor have its own NMT category

[Thomas Stuefe]

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Alexey:
> All right, but I also keep thinking that NMT becomes a wide-spread diagnostic interface, and at some point in the future we should probably exercise a bit of restraint in introducing overly-fine-grained categories.

David:
> I'm fine with this as is (modulo Dan's suggested ObjectMonitor change).
> 
> I agree with @shipilev that as NMT usage expands we are going to need to more carefully consider how we tag things (and whether we need a way to group tags) so that we can try to address fine- and coarse-grained inquiries.

I agree with both of you. I feel the situation is a bit like with UL tags. We introduced them, but at some point stopped thinking about rules. At least I am not aware of any rules. The result is a bit anarchic. With NMT it is less severe though since with UL, due to the fact how tags are combined when forming log expressions, once they exist you never can change them. NMT categories have fewer backward compatibility headaches.

The obvious exception are people who compare NMT output between JVM releases and get confused about numbers that changed. But that's just education.

NMT group tags were mentioned several times in other PRs, and I think that makes sense and is not that hard to do. Especially when done at a shallow level, just as a display thing (e.g. log with fine granularity categories a,b,c,d, then define "mtInternal" as a group of a,b,c,d, which only has to interest the NMT printing code).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7378