1.. highlight:: c 2 3 4.. _memory: 5 6***************** 7Memory Management 8***************** 9 10.. sectionauthor:: Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> 11 12 13 14.. _memoryoverview: 15 16Overview 17======== 18 19Memory management in Python involves a private heap containing all Python 20objects and data structures. The management of this private heap is ensured 21internally by the *Python memory manager*. The Python memory manager has 22different components which deal with various dynamic storage management aspects, 23like sharing, segmentation, preallocation or caching. 24 25At the lowest level, a raw memory allocator ensures that there is enough room in 26the private heap for storing all Python-related data by interacting with the 27memory manager of the operating system. On top of the raw memory allocator, 28several object-specific allocators operate on the same heap and implement 29distinct memory management policies adapted to the peculiarities of every object 30type. For example, integer objects are managed differently within the heap than 31strings, tuples or dictionaries because integers imply different storage 32requirements and speed/space tradeoffs. The Python memory manager thus delegates 33some of the work to the object-specific allocators, but ensures that the latter 34operate within the bounds of the private heap. 35 36It is important to understand that the management of the Python heap is 37performed by the interpreter itself and that the user has no control over it, 38even if they regularly manipulate object pointers to memory blocks inside that 39heap. The allocation of heap space for Python objects and other internal 40buffers is performed on demand by the Python memory manager through the Python/C 41API functions listed in this document. 42 43.. index:: 44 single: malloc() 45 single: calloc() 46 single: realloc() 47 single: free() 48 49To avoid memory corruption, extension writers should never try to operate on 50Python objects with the functions exported by the C library: :c:func:`malloc`, 51:c:func:`calloc`, :c:func:`realloc` and :c:func:`free`. This will result in mixed 52calls between the C allocator and the Python memory manager with fatal 53consequences, because they implement different algorithms and operate on 54different heaps. However, one may safely allocate and release memory blocks 55with the C library allocator for individual purposes, as shown in the following 56example:: 57 58 PyObject *res; 59 char *buf = (char *) malloc(BUFSIZ); /* for I/O */ 60 61 if (buf == NULL) 62 return PyErr_NoMemory(); 63 ...Do some I/O operation involving buf... 64 res = PyBytes_FromString(buf); 65 free(buf); /* malloc'ed */ 66 return res; 67 68In this example, the memory request for the I/O buffer is handled by the C 69library allocator. The Python memory manager is involved only in the allocation 70of the bytes object returned as a result. 71 72In most situations, however, it is recommended to allocate memory from the 73Python heap specifically because the latter is under control of the Python 74memory manager. For example, this is required when the interpreter is extended 75with new object types written in C. Another reason for using the Python heap is 76the desire to *inform* the Python memory manager about the memory needs of the 77extension module. Even when the requested memory is used exclusively for 78internal, highly-specific purposes, delegating all memory requests to the Python 79memory manager causes the interpreter to have a more accurate image of its 80memory footprint as a whole. Consequently, under certain circumstances, the 81Python memory manager may or may not trigger appropriate actions, like garbage 82collection, memory compaction or other preventive procedures. Note that by using 83the C library allocator as shown in the previous example, the allocated memory 84for the I/O buffer escapes completely the Python memory manager. 85 86.. seealso:: 87 88 The :envvar:`PYTHONMALLOC` environment variable can be used to configure 89 the memory allocators used by Python. 90 91 The :envvar:`PYTHONMALLOCSTATS` environment variable can be used to print 92 statistics of the :ref:`pymalloc memory allocator <pymalloc>` every time a 93 new pymalloc object arena is created, and on shutdown. 94 95 96Raw Memory Interface 97==================== 98 99The following function sets are wrappers to the system allocator. These 100functions are thread-safe, the :term:`GIL <global interpreter lock>` does not 101need to be held. 102 103The :ref:`default raw memory allocator <default-memory-allocators>` uses 104the following functions: :c:func:`malloc`, :c:func:`calloc`, :c:func:`realloc` 105and :c:func:`free`; call ``malloc(1)`` (or ``calloc(1, 1)``) when requesting 106zero bytes. 107 108.. versionadded:: 3.4 109 110.. c:function:: void* PyMem_RawMalloc(size_t n) 111 112 Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the 113 allocated memory, or ``NULL`` if the request fails. 114 115 Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as 116 if ``PyMem_RawMalloc(1)`` had been called instead. The memory will not have 117 been initialized in any way. 118 119 120.. c:function:: void* PyMem_RawCalloc(size_t nelem, size_t elsize) 121 122 Allocates *nelem* elements each whose size in bytes is *elsize* and returns 123 a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the 124 request fails. The memory is initialized to zeros. 125 126 Requesting zero elements or elements of size zero bytes returns a distinct 127 non-``NULL`` pointer if possible, as if ``PyMem_RawCalloc(1, 1)`` had been 128 called instead. 129 130 .. versionadded:: 3.5 131 132 133.. c:function:: void* PyMem_RawRealloc(void *p, size_t n) 134 135 Resizes the memory block pointed to by *p* to *n* bytes. The contents will 136 be unchanged to the minimum of the old and the new sizes. 137 138 If *p* is ``NULL``, the call is equivalent to ``PyMem_RawMalloc(n)``; else if 139 *n* is equal to zero, the memory block is resized but is not freed, and the 140 returned pointer is non-``NULL``. 141 142 Unless *p* is ``NULL``, it must have been returned by a previous call to 143 :c:func:`PyMem_RawMalloc`, :c:func:`PyMem_RawRealloc` or 144 :c:func:`PyMem_RawCalloc`. 145 146 If the request fails, :c:func:`PyMem_RawRealloc` returns ``NULL`` and *p* 147 remains a valid pointer to the previous memory area. 148 149 150.. c:function:: void PyMem_RawFree(void *p) 151 152 Frees the memory block pointed to by *p*, which must have been returned by a 153 previous call to :c:func:`PyMem_RawMalloc`, :c:func:`PyMem_RawRealloc` or 154 :c:func:`PyMem_RawCalloc`. Otherwise, or if ``PyMem_RawFree(p)`` has been 155 called before, undefined behavior occurs. 156 157 If *p* is ``NULL``, no operation is performed. 158 159 160.. _memoryinterface: 161 162Memory Interface 163================ 164 165The following function sets, modeled after the ANSI C standard, but specifying 166behavior when requesting zero bytes, are available for allocating and releasing 167memory from the Python heap. 168 169The :ref:`default memory allocator <default-memory-allocators>` uses the 170:ref:`pymalloc memory allocator <pymalloc>`. 171 172.. warning:: 173 174 The :term:`GIL <global interpreter lock>` must be held when using these 175 functions. 176 177.. versionchanged:: 3.6 178 179 The default allocator is now pymalloc instead of system :c:func:`malloc`. 180 181.. c:function:: void* PyMem_Malloc(size_t n) 182 183 Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the 184 allocated memory, or ``NULL`` if the request fails. 185 186 Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as 187 if ``PyMem_Malloc(1)`` had been called instead. The memory will not have 188 been initialized in any way. 189 190 191.. c:function:: void* PyMem_Calloc(size_t nelem, size_t elsize) 192 193 Allocates *nelem* elements each whose size in bytes is *elsize* and returns 194 a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the 195 request fails. The memory is initialized to zeros. 196 197 Requesting zero elements or elements of size zero bytes returns a distinct 198 non-``NULL`` pointer if possible, as if ``PyMem_Calloc(1, 1)`` had been called 199 instead. 200 201 .. versionadded:: 3.5 202 203 204.. c:function:: void* PyMem_Realloc(void *p, size_t n) 205 206 Resizes the memory block pointed to by *p* to *n* bytes. The contents will be 207 unchanged to the minimum of the old and the new sizes. 208 209 If *p* is ``NULL``, the call is equivalent to ``PyMem_Malloc(n)``; else if *n* 210 is equal to zero, the memory block is resized but is not freed, and the 211 returned pointer is non-``NULL``. 212 213 Unless *p* is ``NULL``, it must have been returned by a previous call to 214 :c:func:`PyMem_Malloc`, :c:func:`PyMem_Realloc` or :c:func:`PyMem_Calloc`. 215 216 If the request fails, :c:func:`PyMem_Realloc` returns ``NULL`` and *p* remains 217 a valid pointer to the previous memory area. 218 219 220.. c:function:: void PyMem_Free(void *p) 221 222 Frees the memory block pointed to by *p*, which must have been returned by a 223 previous call to :c:func:`PyMem_Malloc`, :c:func:`PyMem_Realloc` or 224 :c:func:`PyMem_Calloc`. Otherwise, or if ``PyMem_Free(p)`` has been called 225 before, undefined behavior occurs. 226 227 If *p* is ``NULL``, no operation is performed. 228 229The following type-oriented macros are provided for convenience. Note that 230*TYPE* refers to any C type. 231 232 233.. c:function:: TYPE* PyMem_New(TYPE, size_t n) 234 235 Same as :c:func:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes of 236 memory. Returns a pointer cast to :c:type:`TYPE*`. The memory will not have 237 been initialized in any way. 238 239 240.. c:function:: TYPE* PyMem_Resize(void *p, TYPE, size_t n) 241 242 Same as :c:func:`PyMem_Realloc`, but the memory block is resized to ``(n * 243 sizeof(TYPE))`` bytes. Returns a pointer cast to :c:type:`TYPE*`. On return, 244 *p* will be a pointer to the new memory area, or ``NULL`` in the event of 245 failure. 246 247 This is a C preprocessor macro; *p* is always reassigned. Save the original 248 value of *p* to avoid losing memory when handling errors. 249 250 251.. c:function:: void PyMem_Del(void *p) 252 253 Same as :c:func:`PyMem_Free`. 254 255In addition, the following macro sets are provided for calling the Python memory 256allocator directly, without involving the C API functions listed above. However, 257note that their use does not preserve binary compatibility across Python 258versions and is therefore deprecated in extension modules. 259 260* ``PyMem_MALLOC(size)`` 261* ``PyMem_NEW(type, size)`` 262* ``PyMem_REALLOC(ptr, size)`` 263* ``PyMem_RESIZE(ptr, type, size)`` 264* ``PyMem_FREE(ptr)`` 265* ``PyMem_DEL(ptr)`` 266 267 268Object allocators 269================= 270 271The following function sets, modeled after the ANSI C standard, but specifying 272behavior when requesting zero bytes, are available for allocating and releasing 273memory from the Python heap. 274 275The :ref:`default object allocator <default-memory-allocators>` uses the 276:ref:`pymalloc memory allocator <pymalloc>`. 277 278.. warning:: 279 280 The :term:`GIL <global interpreter lock>` must be held when using these 281 functions. 282 283.. c:function:: void* PyObject_Malloc(size_t n) 284 285 Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the 286 allocated memory, or ``NULL`` if the request fails. 287 288 Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as 289 if ``PyObject_Malloc(1)`` had been called instead. The memory will not have 290 been initialized in any way. 291 292 293.. c:function:: void* PyObject_Calloc(size_t nelem, size_t elsize) 294 295 Allocates *nelem* elements each whose size in bytes is *elsize* and returns 296 a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the 297 request fails. The memory is initialized to zeros. 298 299 Requesting zero elements or elements of size zero bytes returns a distinct 300 non-``NULL`` pointer if possible, as if ``PyObject_Calloc(1, 1)`` had been called 301 instead. 302 303 .. versionadded:: 3.5 304 305 306.. c:function:: void* PyObject_Realloc(void *p, size_t n) 307 308 Resizes the memory block pointed to by *p* to *n* bytes. The contents will be 309 unchanged to the minimum of the old and the new sizes. 310 311 If *p* is ``NULL``, the call is equivalent to ``PyObject_Malloc(n)``; else if *n* 312 is equal to zero, the memory block is resized but is not freed, and the 313 returned pointer is non-``NULL``. 314 315 Unless *p* is ``NULL``, it must have been returned by a previous call to 316 :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc` or :c:func:`PyObject_Calloc`. 317 318 If the request fails, :c:func:`PyObject_Realloc` returns ``NULL`` and *p* remains 319 a valid pointer to the previous memory area. 320 321 322.. c:function:: void PyObject_Free(void *p) 323 324 Frees the memory block pointed to by *p*, which must have been returned by a 325 previous call to :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc` or 326 :c:func:`PyObject_Calloc`. Otherwise, or if ``PyObject_Free(p)`` has been called 327 before, undefined behavior occurs. 328 329 If *p* is ``NULL``, no operation is performed. 330 331 332.. _default-memory-allocators: 333 334Default Memory Allocators 335========================= 336 337Default memory allocators: 338 339=============================== ==================== ================== ===================== ==================== 340Configuration Name PyMem_RawMalloc PyMem_Malloc PyObject_Malloc 341=============================== ==================== ================== ===================== ==================== 342Release build ``"pymalloc"`` ``malloc`` ``pymalloc`` ``pymalloc`` 343Debug build ``"pymalloc_debug"`` ``malloc`` + debug ``pymalloc`` + debug ``pymalloc`` + debug 344Release build, without pymalloc ``"malloc"`` ``malloc`` ``malloc`` ``malloc`` 345Debug build, without pymalloc ``"malloc_debug"`` ``malloc`` + debug ``malloc`` + debug ``malloc`` + debug 346=============================== ==================== ================== ===================== ==================== 347 348Legend: 349 350* Name: value for :envvar:`PYTHONMALLOC` environment variable 351* ``malloc``: system allocators from the standard C library, C functions: 352 :c:func:`malloc`, :c:func:`calloc`, :c:func:`realloc` and :c:func:`free` 353* ``pymalloc``: :ref:`pymalloc memory allocator <pymalloc>` 354* "+ debug": with debug hooks installed by :c:func:`PyMem_SetupDebugHooks` 355 356 357Customize Memory Allocators 358=========================== 359 360.. versionadded:: 3.4 361 362.. c:type:: PyMemAllocatorEx 363 364 Structure used to describe a memory block allocator. The structure has 365 four fields: 366 367 +----------------------------------------------------------+---------------------------------------+ 368 | Field | Meaning | 369 +==========================================================+=======================================+ 370 | ``void *ctx`` | user context passed as first argument | 371 +----------------------------------------------------------+---------------------------------------+ 372 | ``void* malloc(void *ctx, size_t size)`` | allocate a memory block | 373 +----------------------------------------------------------+---------------------------------------+ 374 | ``void* calloc(void *ctx, size_t nelem, size_t elsize)`` | allocate a memory block initialized | 375 | | with zeros | 376 +----------------------------------------------------------+---------------------------------------+ 377 | ``void* realloc(void *ctx, void *ptr, size_t new_size)`` | allocate or resize a memory block | 378 +----------------------------------------------------------+---------------------------------------+ 379 | ``void free(void *ctx, void *ptr)`` | free a memory block | 380 +----------------------------------------------------------+---------------------------------------+ 381 382 .. versionchanged:: 3.5 383 The :c:type:`PyMemAllocator` structure was renamed to 384 :c:type:`PyMemAllocatorEx` and a new ``calloc`` field was added. 385 386 387.. c:type:: PyMemAllocatorDomain 388 389 Enum used to identify an allocator domain. Domains: 390 391 .. c:macro:: PYMEM_DOMAIN_RAW 392 393 Functions: 394 395 * :c:func:`PyMem_RawMalloc` 396 * :c:func:`PyMem_RawRealloc` 397 * :c:func:`PyMem_RawCalloc` 398 * :c:func:`PyMem_RawFree` 399 400 .. c:macro:: PYMEM_DOMAIN_MEM 401 402 Functions: 403 404 * :c:func:`PyMem_Malloc`, 405 * :c:func:`PyMem_Realloc` 406 * :c:func:`PyMem_Calloc` 407 * :c:func:`PyMem_Free` 408 409 .. c:macro:: PYMEM_DOMAIN_OBJ 410 411 Functions: 412 413 * :c:func:`PyObject_Malloc` 414 * :c:func:`PyObject_Realloc` 415 * :c:func:`PyObject_Calloc` 416 * :c:func:`PyObject_Free` 417 418.. c:function:: void PyMem_GetAllocator(PyMemAllocatorDomain domain, PyMemAllocatorEx *allocator) 419 420 Get the memory block allocator of the specified domain. 421 422 423.. c:function:: void PyMem_SetAllocator(PyMemAllocatorDomain domain, PyMemAllocatorEx *allocator) 424 425 Set the memory block allocator of the specified domain. 426 427 The new allocator must return a distinct non-``NULL`` pointer when requesting 428 zero bytes. 429 430 For the :c:data:`PYMEM_DOMAIN_RAW` domain, the allocator must be 431 thread-safe: the :term:`GIL <global interpreter lock>` is not held when the 432 allocator is called. 433 434 If the new allocator is not a hook (does not call the previous allocator), 435 the :c:func:`PyMem_SetupDebugHooks` function must be called to reinstall the 436 debug hooks on top on the new allocator. 437 438 439.. c:function:: void PyMem_SetupDebugHooks(void) 440 441 Setup hooks to detect bugs in the Python memory allocator functions. 442 443 Newly allocated memory is filled with the byte ``0xCD`` (``CLEANBYTE``), 444 freed memory is filled with the byte ``0xDD`` (``DEADBYTE``). Memory blocks 445 are surrounded by "forbidden bytes" (``FORBIDDENBYTE``: byte ``0xFD``). 446 447 Runtime checks: 448 449 - Detect API violations, ex: :c:func:`PyObject_Free` called on a buffer 450 allocated by :c:func:`PyMem_Malloc` 451 - Detect write before the start of the buffer (buffer underflow) 452 - Detect write after the end of the buffer (buffer overflow) 453 - Check that the :term:`GIL <global interpreter lock>` is held when 454 allocator functions of :c:data:`PYMEM_DOMAIN_OBJ` (ex: 455 :c:func:`PyObject_Malloc`) and :c:data:`PYMEM_DOMAIN_MEM` (ex: 456 :c:func:`PyMem_Malloc`) domains are called 457 458 On error, the debug hooks use the :mod:`tracemalloc` module to get the 459 traceback where a memory block was allocated. The traceback is only 460 displayed if :mod:`tracemalloc` is tracing Python memory allocations and the 461 memory block was traced. 462 463 These hooks are :ref:`installed by default <default-memory-allocators>` if 464 Python is compiled in debug 465 mode. The :envvar:`PYTHONMALLOC` environment variable can be used to install 466 debug hooks on a Python compiled in release mode. 467 468 .. versionchanged:: 3.6 469 This function now also works on Python compiled in release mode. 470 On error, the debug hooks now use :mod:`tracemalloc` to get the traceback 471 where a memory block was allocated. The debug hooks now also check 472 if the GIL is held when functions of :c:data:`PYMEM_DOMAIN_OBJ` and 473 :c:data:`PYMEM_DOMAIN_MEM` domains are called. 474 475 .. versionchanged:: 3.8 476 Byte patterns ``0xCB`` (``CLEANBYTE``), ``0xDB`` (``DEADBYTE``) and 477 ``0xFB`` (``FORBIDDENBYTE``) have been replaced with ``0xCD``, ``0xDD`` 478 and ``0xFD`` to use the same values than Windows CRT debug ``malloc()`` 479 and ``free()``. 480 481 482.. _pymalloc: 483 484The pymalloc allocator 485====================== 486 487Python has a *pymalloc* allocator optimized for small objects (smaller or equal 488to 512 bytes) with a short lifetime. It uses memory mappings called "arenas" 489with a fixed size of 256 KiB. It falls back to :c:func:`PyMem_RawMalloc` and 490:c:func:`PyMem_RawRealloc` for allocations larger than 512 bytes. 491 492*pymalloc* is the :ref:`default allocator <default-memory-allocators>` of the 493:c:data:`PYMEM_DOMAIN_MEM` (ex: :c:func:`PyMem_Malloc`) and 494:c:data:`PYMEM_DOMAIN_OBJ` (ex: :c:func:`PyObject_Malloc`) domains. 495 496The arena allocator uses the following functions: 497 498* :c:func:`VirtualAlloc` and :c:func:`VirtualFree` on Windows, 499* :c:func:`mmap` and :c:func:`munmap` if available, 500* :c:func:`malloc` and :c:func:`free` otherwise. 501 502Customize pymalloc Arena Allocator 503---------------------------------- 504 505.. versionadded:: 3.4 506 507.. c:type:: PyObjectArenaAllocator 508 509 Structure used to describe an arena allocator. The structure has 510 three fields: 511 512 +--------------------------------------------------+---------------------------------------+ 513 | Field | Meaning | 514 +==================================================+=======================================+ 515 | ``void *ctx`` | user context passed as first argument | 516 +--------------------------------------------------+---------------------------------------+ 517 | ``void* alloc(void *ctx, size_t size)`` | allocate an arena of size bytes | 518 +--------------------------------------------------+---------------------------------------+ 519 | ``void free(void *ctx, size_t size, void *ptr)`` | free an arena | 520 +--------------------------------------------------+---------------------------------------+ 521 522.. c:function:: void PyObject_GetArenaAllocator(PyObjectArenaAllocator *allocator) 523 524 Get the arena allocator. 525 526.. c:function:: void PyObject_SetArenaAllocator(PyObjectArenaAllocator *allocator) 527 528 Set the arena allocator. 529 530 531tracemalloc C API 532================= 533 534.. versionadded:: 3.7 535 536.. c:function:: int PyTraceMalloc_Track(unsigned int domain, uintptr_t ptr, size_t size) 537 538 Track an allocated memory block in the :mod:`tracemalloc` module. 539 540 Return ``0`` on success, return ``-1`` on error (failed to allocate memory to 541 store the trace). Return ``-2`` if tracemalloc is disabled. 542 543 If memory block is already tracked, update the existing trace. 544 545.. c:function:: int PyTraceMalloc_Untrack(unsigned int domain, uintptr_t ptr) 546 547 Untrack an allocated memory block in the :mod:`tracemalloc` module. 548 Do nothing if the block was not tracked. 549 550 Return ``-2`` if tracemalloc is disabled, otherwise return ``0``. 551 552 553.. _memoryexamples: 554 555Examples 556======== 557 558Here is the example from section :ref:`memoryoverview`, rewritten so that the 559I/O buffer is allocated from the Python heap by using the first function set:: 560 561 PyObject *res; 562 char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */ 563 564 if (buf == NULL) 565 return PyErr_NoMemory(); 566 /* ...Do some I/O operation involving buf... */ 567 res = PyBytes_FromString(buf); 568 PyMem_Free(buf); /* allocated with PyMem_Malloc */ 569 return res; 570 571The same code using the type-oriented function set:: 572 573 PyObject *res; 574 char *buf = PyMem_New(char, BUFSIZ); /* for I/O */ 575 576 if (buf == NULL) 577 return PyErr_NoMemory(); 578 /* ...Do some I/O operation involving buf... */ 579 res = PyBytes_FromString(buf); 580 PyMem_Del(buf); /* allocated with PyMem_New */ 581 return res; 582 583Note that in the two examples above, the buffer is always manipulated via 584functions belonging to the same set. Indeed, it is required to use the same 585memory API family for a given memory block, so that the risk of mixing different 586allocators is reduced to a minimum. The following code sequence contains two 587errors, one of which is labeled as *fatal* because it mixes two different 588allocators operating on different heaps. :: 589 590 char *buf1 = PyMem_New(char, BUFSIZ); 591 char *buf2 = (char *) malloc(BUFSIZ); 592 char *buf3 = (char *) PyMem_Malloc(BUFSIZ); 593 ... 594 PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */ 595 free(buf2); /* Right -- allocated via malloc() */ 596 free(buf1); /* Fatal -- should be PyMem_Del() */ 597 598In addition to the functions aimed at handling raw memory blocks from the Python 599heap, objects in Python are allocated and released with :c:func:`PyObject_New`, 600:c:func:`PyObject_NewVar` and :c:func:`PyObject_Del`. 601 602These will be explained in the next chapter on defining and implementing new 603object types in C. 604 605