blob: 18abe983888362cd9eab97f4caa82ad35e8960a5 [file] [log] [blame]
Fred Drake3adf79e2001-10-12 19:01:43 +00001\chapter{Memory Management \label{memory}}
2\sectionauthor{Vladimir Marangozov}{Vladimir.Marangozov@inrialpes.fr}
3
4
5\section{Overview \label{memoryOverview}}
6
7Memory management in Python involves a private heap containing all
8Python objects and data structures. The management of this private
9heap is ensured internally by the \emph{Python memory manager}. The
10Python memory manager has different components which deal with various
11dynamic storage management aspects, like sharing, segmentation,
12preallocation or caching.
13
14At the lowest level, a raw memory allocator ensures that there is
15enough room in the private heap for storing all Python-related data
16by interacting with the memory manager of the operating system. On top
17of the raw memory allocator, several object-specific allocators
18operate on the same heap and implement distinct memory management
19policies adapted to the peculiarities of every object type. For
20example, integer objects are managed differently within the heap than
21strings, tuples or dictionaries because integers imply different
22storage requirements and speed/space tradeoffs. The Python memory
23manager thus delegates some of the work to the object-specific
24allocators, but ensures that the latter operate within the bounds of
25the private heap.
26
27It is important to understand that the management of the Python heap
28is performed by the interpreter itself and that the user has no
Tim Peters87bbdd32002-04-06 09:14:33 +000029control over it, even if she regularly manipulates object pointers to
Fred Drake3adf79e2001-10-12 19:01:43 +000030memory blocks inside that heap. The allocation of heap space for
31Python objects and other internal buffers is performed on demand by
32the Python memory manager through the Python/C API functions listed in
33this document.
34
35To avoid memory corruption, extension writers should never try to
36operate on Python objects with the functions exported by the C
37library: \cfunction{malloc()}\ttindex{malloc()},
38\cfunction{calloc()}\ttindex{calloc()},
39\cfunction{realloc()}\ttindex{realloc()} and
40\cfunction{free()}\ttindex{free()}. This will result in
41mixed calls between the C allocator and the Python memory manager
42with fatal consequences, because they implement different algorithms
43and operate on different heaps. However, one may safely allocate and
44release memory blocks with the C library allocator for individual
45purposes, as shown in the following example:
46
47\begin{verbatim}
48 PyObject *res;
49 char *buf = (char *) malloc(BUFSIZ); /* for I/O */
50
51 if (buf == NULL)
52 return PyErr_NoMemory();
53 ...Do some I/O operation involving buf...
54 res = PyString_FromString(buf);
55 free(buf); /* malloc'ed */
56 return res;
57\end{verbatim}
58
59In this example, the memory request for the I/O buffer is handled by
60the C library allocator. The Python memory manager is involved only
61in the allocation of the string object returned as a result.
62
63In most situations, however, it is recommended to allocate memory from
64the Python heap specifically because the latter is under control of
65the Python memory manager. For example, this is required when the
66interpreter is extended with new object types written in C. Another
67reason for using the Python heap is the desire to \emph{inform} the
68Python memory manager about the memory needs of the extension module.
69Even when the requested memory is used exclusively for internal,
70highly-specific purposes, delegating all memory requests to the Python
71memory manager causes the interpreter to have a more accurate image of
72its memory footprint as a whole. Consequently, under certain
73circumstances, the Python memory manager may or may not trigger
74appropriate actions, like garbage collection, memory compaction or
75other preventive procedures. Note that by using the C library
76allocator as shown in the previous example, the allocated memory for
77the I/O buffer escapes completely the Python memory manager.
78
79
80\section{Memory Interface \label{memoryInterface}}
81
Tim Peters87bbdd32002-04-06 09:14:33 +000082The following function sets, modeled after the ANSI C standard,
83but specifying behavior when requesting zero bytes,
84are available for allocating and releasing memory from the Python heap:
Fred Drake3adf79e2001-10-12 19:01:43 +000085
86
87\begin{cfuncdesc}{void*}{PyMem_Malloc}{size_t n}
88 Allocates \var{n} bytes and returns a pointer of type \ctype{void*}
89 to the allocated memory, or \NULL{} if the request fails.
Tim Peters87bbdd32002-04-06 09:14:33 +000090 Requesting zero bytes returns a distinct non-\NULL{} pointer if
91 possible, as if \cfunction{PyMem_Malloc(1)} had been called instead.
Fred Drake3adf79e2001-10-12 19:01:43 +000092 The memory will not have been initialized in any way.
93\end{cfuncdesc}
94
95\begin{cfuncdesc}{void*}{PyMem_Realloc}{void *p, size_t n}
96 Resizes the memory block pointed to by \var{p} to \var{n} bytes.
97 The contents will be unchanged to the minimum of the old and the new
98 sizes. If \var{p} is \NULL, the call is equivalent to
Tim Peters87bbdd32002-04-06 09:14:33 +000099 \cfunction{PyMem_Malloc(\var{n})}; else if \var{n} is equal to zero, the
Fred Drake3adf79e2001-10-12 19:01:43 +0000100 memory block is resized but is not freed, and the returned pointer
101 is non-\NULL. Unless \var{p} is \NULL, it must have been
102 returned by a previous call to \cfunction{PyMem_Malloc()} or
Guido van Rossumd8faa362007-04-27 19:54:29 +0000103 \cfunction{PyMem_Realloc()}. If the request fails,
104 \cfunction{PyMem_Realloc()} returns \NULL{} and \var{p} remains a
105 valid pointer to the previous memory area.
Fred Drake3adf79e2001-10-12 19:01:43 +0000106\end{cfuncdesc}
107
108\begin{cfuncdesc}{void}{PyMem_Free}{void *p}
109 Frees the memory block pointed to by \var{p}, which must have been
110 returned by a previous call to \cfunction{PyMem_Malloc()} or
111 \cfunction{PyMem_Realloc()}. Otherwise, or if
112 \cfunction{PyMem_Free(p)} has been called before, undefined
Tim Peters87bbdd32002-04-06 09:14:33 +0000113 behavior occurs. If \var{p} is \NULL, no operation is performed.
Fred Drake3adf79e2001-10-12 19:01:43 +0000114\end{cfuncdesc}
115
116The following type-oriented macros are provided for convenience. Note
117that \var{TYPE} refers to any C type.
118
119\begin{cfuncdesc}{\var{TYPE}*}{PyMem_New}{TYPE, size_t n}
120 Same as \cfunction{PyMem_Malloc()}, but allocates \code{(\var{n} *
121 sizeof(\var{TYPE}))} bytes of memory. Returns a pointer cast to
122 \ctype{\var{TYPE}*}. The memory will not have been initialized in
123 any way.
124\end{cfuncdesc}
125
126\begin{cfuncdesc}{\var{TYPE}*}{PyMem_Resize}{void *p, TYPE, size_t n}
127 Same as \cfunction{PyMem_Realloc()}, but the memory block is resized
128 to \code{(\var{n} * sizeof(\var{TYPE}))} bytes. Returns a pointer
Guido van Rossumd8faa362007-04-27 19:54:29 +0000129 cast to \ctype{\var{TYPE}*}. On return, \var{p} will be a pointer to
130 the new memory area, or \NULL{} in the event of failure.
Fred Drake3adf79e2001-10-12 19:01:43 +0000131\end{cfuncdesc}
132
133\begin{cfuncdesc}{void}{PyMem_Del}{void *p}
134 Same as \cfunction{PyMem_Free()}.
135\end{cfuncdesc}
136
137In addition, the following macro sets are provided for calling the
138Python memory allocator directly, without involving the C API functions
139listed above. However, note that their use does not preserve binary
Raymond Hettinger68804312005-01-01 00:28:46 +0000140compatibility across Python versions and is therefore deprecated in
Fred Drake3adf79e2001-10-12 19:01:43 +0000141extension modules.
142
143\cfunction{PyMem_MALLOC()}, \cfunction{PyMem_REALLOC()}, \cfunction{PyMem_FREE()}.
144
145\cfunction{PyMem_NEW()}, \cfunction{PyMem_RESIZE()}, \cfunction{PyMem_DEL()}.
146
147
148\section{Examples \label{memoryExamples}}
149
150Here is the example from section \ref{memoryOverview}, rewritten so
151that the I/O buffer is allocated from the Python heap by using the
152first function set:
153
154\begin{verbatim}
155 PyObject *res;
156 char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */
157
158 if (buf == NULL)
159 return PyErr_NoMemory();
160 /* ...Do some I/O operation involving buf... */
161 res = PyString_FromString(buf);
162 PyMem_Free(buf); /* allocated with PyMem_Malloc */
163 return res;
164\end{verbatim}
165
166The same code using the type-oriented function set:
167
168\begin{verbatim}
169 PyObject *res;
170 char *buf = PyMem_New(char, BUFSIZ); /* for I/O */
171
172 if (buf == NULL)
173 return PyErr_NoMemory();
174 /* ...Do some I/O operation involving buf... */
175 res = PyString_FromString(buf);
176 PyMem_Del(buf); /* allocated with PyMem_New */
177 return res;
178\end{verbatim}
179
180Note that in the two examples above, the buffer is always
181manipulated via functions belonging to the same set. Indeed, it
182is required to use the same memory API family for a given
183memory block, so that the risk of mixing different allocators is
184reduced to a minimum. The following code sequence contains two errors,
185one of which is labeled as \emph{fatal} because it mixes two different
186allocators operating on different heaps.
187
188\begin{verbatim}
189char *buf1 = PyMem_New(char, BUFSIZ);
190char *buf2 = (char *) malloc(BUFSIZ);
191char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
192...
193PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */
194free(buf2); /* Right -- allocated via malloc() */
195free(buf1); /* Fatal -- should be PyMem_Del() */
196\end{verbatim}
197
198In addition to the functions aimed at handling raw memory blocks from
199the Python heap, objects in Python are allocated and released with
200\cfunction{PyObject_New()}, \cfunction{PyObject_NewVar()} and
Thomas Wouters49fd7fa2006-04-21 10:40:58 +0000201\cfunction{PyObject_Del()}.
Fred Drake3adf79e2001-10-12 19:01:43 +0000202
203These will be explained in the next chapter on defining and
204implementing new object types in C.