Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT)

[Carter Kozak]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221130/ef0fd315/attachment.htm>