RFR: 8157023: Integrate NMT with JFR

Erik Gahlin egahlin at openjdk.org
Thu Dec 1 13:27:15 UTC 2022


On Thu, 1 Dec 2022 12:27:42 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 832:
>> 
>>> 830: 
>>> 831:   MemBaseline usage;
>>> 832:   usage.baseline(true);
>> 
>> In an ideal world we could report totals and category information from the same snapshot, however the periodic event infrastructure doesn’t seem to provide a great way to do that. I don’t think that’s a big deal, but may be worth documenting to avoid confusion as totals may be reported lower than the sum of the parts due to temporal drift.
>> 
>> An option I had considered is to define some form of larger “NMTSummary” event with reserved+committed fields for each category as well as the totals. The reporting structure would align with the existing NMT summary tooling, but the event would need to be kept up to date with new NMT types, which may not be worthwhile (unless we can create dynamic events using the c apis, which would make things easier). Unclear how this data would be visualized out of the box. I don’t have as much context as I’d like around event design considerations, there may be other reasons I’m not aware of that this suggestion is a bad idea.
>
> I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 
> 
> I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.

I think we should design the events as if we could take everything in one snapshot. That way, we can improve the implementation later. It would be good to write in the event description of NativeMemoryUsage event that it may not add exactly up to the sum of NativeMemoryUsagePart events due to timing issues.

I will look into adding support for snapshots, but it will have to be a later release.

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

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


More information about the hotspot-dev mailing list