Proposal: Extend Native Memory Tracking across the whole process via interposition

Nathan Reynolds numeralnathan at gmail.com
Wed Dec 6 20:06:27 UTC 2023


JFR has some settings to enable allocation tracking in the Java heap.  This
isn't enabled by default because it can have some performance impact.  I am
not sure how it is done without killing performance.  Perhaps, we can do
something similar for native memory allocations.  Also, I suspect that
allocations to native memory is much slower than to allocations to Java
heap.  So, the overhead of tracking native memory allocations should be
less than tracking Java allocations.

On Wed, Dec 6, 2023 at 12:44 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

>
> On Tue, Dec 5, 2023 at 7:04 PM Nathan Reynolds <numeralnathan at gmail.com>
> wrote:
>
>> Can we have the native memory allocations push JFR events?  This would
>> only happen when enabled.  This would make native memory allocation
>> analysis very easy to do in Mission Control.
>>
>
> Technically, nothing is preventing us from doing so; I'd be worried about
> the overhead though when doing this for every malloc. mmap is probably less
> of a problem.
>
> At the moment, NMT events are send periodically; one could add a
> threshold-based approach (whenever we reach +1M in any category), but that
> would give you only sporadic call stacks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20231206/e6aa8e27/attachment.htm>


More information about the jdk-dev mailing list