When new objects are created, the allocation code ends calling into _Py_NewReference (with some exceptions). tracemalloc has a hook into this function to correlate allocations and traces (that do not know anything about objects or references) with newly created objects. This happens here:
|
if (_Py_tracemalloc_config.tracing) { |
|
_PyTraceMalloc_NewReference(op); |
|
} |
This allows tracemalloc to be able to return the traceback where objects where allocated, which is great. Unfortunately other debuggers and profilers do not have this capability as there is no way to leverage trace malloc functionality or to hook into object creation.
I propose to expose an API (unclear what layer of the C-API this should be in) where callbacks can be registered to be called in _Py_NewReference and switch tracemalloc to use this API.
Linked PRs
When new objects are created, the allocation code ends calling into
_Py_NewReference(with some exceptions).tracemallochas a hook into this function to correlate allocations and traces (that do not know anything about objects or references) with newly created objects. This happens here:cpython/Objects/object.c
Lines 2018 to 2020 in 3d647e7
This allows
tracemallocto be able to return the traceback where objects where allocated, which is great. Unfortunately other debuggers and profilers do not have this capability as there is no way to leverage trace malloc functionality or to hook into object creation.I propose to expose an API (unclear what layer of the C-API this should be in) where callbacks can be registered to be called in
_Py_NewReferenceand switch tracemalloc to use this API.Linked PRs