feat: enable memory profiling - #1266
Conversation
a77e8ad to
6cbb5b3
Compare
|
@microsoft-github-policy-service agree company="Datadog" |
5381881 to
8881bca
Compare
8881bca to
6277a20
Compare
|
Over in OpenTelemetry we are currently looking at adding memory profiling to the ebpf/full-host profiler. This mechanism would make it easy for us to plug our sample points in here! |
|
Thank you for the nice PR Daniel Schwartz-Narbonne (@danielsn) -- and apologies for the slow response :-(. It looks quite interesting and I think it is a great starting point to start exploring the right primitives needed for profiling tools. To me, an important goal would be to make it cheap enough that it can be enabled generally in production without too much of a performance hit when the profiler is not enabled (and also fast enough when profiling with reasonable sample rates). |
This is a draft proposal to add memory allocation and live heap profiling to mimalloc, following the discussion in #1070 .
For allocation profiling, this provides a callback that could be used to trigger the probe for an external profiler, or to directly sample and store the values for in-process profiling.
Supporting live-heap profiling requires a cheap way of knowing whether a given pointer was tracked when free is called. Doing so externally turns out to be surprisingly expensive, as even a hash-table incurs cache misses, which are avoided if the metadata lives on the same cache line as an allocator data stucture that will already be read as part of the free operation. In this case, the on_free callback could either do in-process or out-of-process untracking of the object. In the common case where there is no tracked object on the page, this is a single branch on data that is already in cache.