RFR: 8157023: Integrate NMT with JFR

[Stefan Johansson]

On Thu, 1 Dec 2022 18:41:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The number of values may expand considerably in the future: we may want to use tags in a far more fine-granular manner than we do now, and/or change their encoding - eg to work in a hierarchy, or groups, or in combined an UL-like fashion. So their number may expand, and their meaning change, which could render this report obsolete quickly. E.g. if we add tag hierarchies, do we then only report leaf tags? How useful would that be? If we allow tag combinations, how would we report that?
> 

As you know I would love to see a better way to tag allocations than the current. It is hard to answer how we would handle it when it comes but the current event structure could already handle for example multiple tags. The `type` field could look like "gc,remset" leaving it to the parser to decide how to handle this data. Not saying this is perfect or the way to go, but I would not like to engineer the initial solution to fit a possible future improvement. That said, we should of course try to avoid making design decisions that will restrict us going forward. One way would be to let those new events be `experimental` at first.

> Also note that I currently work on a patch for showing NMT peak malloc values, see https://bugs.openjdk.org/browse/JDK-8297958. Peak values are very useful to have. So, do we expose them too? One more value per category. But leaving them out would render the JFR NMT report less useful.
> 

This is another good question, my first thought was to include more information. Like the split between malloced and "mapped", but after some discussions we landed in just the two current valued. I don't see a problem adding the peak value, but would it also require the "normal" malloc value to make sense?

> Bottomline, I am not yet convinced that reporting all NMT categories is that useful. And it exposes implementation details that may cause breakage in the future. We could restrict them to a subset of useful ones, and only report that.
> 

I'm not against this, for obvious reasons I care mostly about GC, and I could see a benefit in just reporting a few "subsets". The problem I see with this is that someone might be needing something other that what we defined. We can of course add more later on, but right now when it is just around 30 events I think sending all is ok.

> Another thought, for virtual memory mappings you report reserved and committed. But I doubt that "reserved" is really of much use. In itself, it does not cost anything, at least not on 64-bit. For a select few categories, it can signify the largest amount of committable memory (e.g. heap and code space) but those are already reported in JFR. So I think we could omit "reserved" and save a bunch of code and make the NMT JFR report less overwhelming.
> 

I see your point, and I agree that committed is the most interesting one. The way I use it is exactly as you describe, it is an easy way to determine the max and even if that information is available through other events it is quite nice to have it bundled together.

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

PR: https://git.openjdk.org/jdk/pull/11449