This looks fantastic, thank you so much! I can confirm that the proposed design would solve my use-case.
I'd enjoy discussing the NMT event contract somewhere more specific to the implementation, but I don't want to muddle this thread with implementation details. Carter Kozak On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote: > Hi Carter, > > Your mail made me pick up an old item from my wishlist: to have native > memory tracking information available in JFR recordings. When we, in GC, > do improvements to decrease the native memory overhead of our > algorithms, NMT is a very good tool to track the progress. We have > scripts that sound very similar to what you describe and more than once > I've been thinking about adding this information into JFR. But it has > not been a priority and the greater value has been unclear. > > Hearing that others might also benefit from such a change I took a > discussion with the JFR team on how to best proceed with this. I have > created a branch for this and will probably create a PR for it shortly, > but I thought I would drop it here first: > https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt > > The change adds two new JFR events: one for the total usage and one for > the usage of each memory type. These are sent only if Native Memory > Tracking is turned on, and they are enabled in the default JFR profile > with an interval of 1s. This might change during reviewing but it was a > good starting point. > > With this you will be able to use JFR streaming to access the events > from within your running process. I hope this will help your use cases > and please let us know if you have any comments or suggestions. > > Thanks, > Stefan
