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

[Brice Dutheil]

I would like to see JFR events with a stack as well, but it is maybe too
much for an initial implementation?
Also there are alternatives for that using async-profiler.

-- Brice


On Wed, Dec 6, 2023 at 9:06 PM Nathan Reynolds <numeralnathan at gmail.com>
wrote:

> 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/846576fc/attachment-0001.htm>