summaryrefslogtreecommitdiffstats
path: root/Objects/obmalloc.c
Commit message (Collapse)AuthorAgeFilesLines
* Bug #3951: Py_USING_MEMORY_DEBUGGER should not be enabled by default.Martin v. Löwis2008-09-251-1/+1
|
* Issue #3642: Suppress warning in obmalloc when size_t isMartin v. Löwis2008-09-111-1/+3
| | | | larger than uint. Reverts r65975. Reviewed by Brett Cannon.
* Changed type of numarenas from uint to size_t to silence a GCC warning on ↵Christian Heimes2008-08-221-1/+1
| | | | 64bit OSes. Reviewed by Benjamin Peterson.
* Issue #2620: Overflow checking when allocating or reallocating memoryGregory P. Smith2008-07-221-0/+18
| | | | | | | | was not always being done properly in some python types and extension modules. PyMem_MALLOC, PyMem_REALLOC, PyMem_NEW and PyMem_RESIZE have all been updated to perform better checks and places in the code that would previously leak memory on the error path when such an allocation failed have been fixed.
* Merge in release25-maint r60793:Gregory P. Smith2008-06-111-2/+2
| | | | | | Added checks for integer overflows, contributed by Google. Some are only available if asserts are left in the code, in cases where they can't be triggered from Python code.
* PEP 3123: Provide forward compatibility with Python 3.0, while keepingMartin v. Löwis2007-07-211-1/+1
| | | | | backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT.
* Don't inline Py_ADDRESS_IN_RANGE with gcc 4+ either.Neal Norwitz2006-10-281-1/+2
| | | | Will backport.
* _PyObject_DebugMalloc(): The return value should addTim Peters2006-06-041-1/+1
| | | | | 2*sizeof(size_t) now, not 8. This probably accounts for current disasters on the 64-bit buildbot slaves.
* In a PYMALLOC_DEBUG build obmalloc adds extra debugging infoTim Peters2006-06-041-116/+124
| | | | | | | | | | | | | | | | | to each allocated block. This was using 4 bytes for each such piece of info regardless of platform. This didn't really matter before (proof: no bug reports, and the debug-build obmalloc would have assert-failed if it was ever asked for a chunk of memory >= 2**32 bytes), since container indices were plain ints. But after the Py_ssize_t changes, it's at least theoretically possible to allocate a list or string whose guts exceed 2**32 bytes, and the PYMALLOC_DEBUG routines would fail then (having only 4 bytes to record the originally requested size). Now we use sizeof(size_t) bytes for each of a PYMALLOC_DEBUG build's extra debugging fields. This won't make any difference on 32-bit boxes, but will add 16 bytes to each allocation in a debug build on a 64-bit box.
* Get compiling againNeal Norwitz2006-04-111-1/+1
|
* More low-hanging fruit. Still need to re-arrange some code (or find a betterAnthony Baxter2006-04-111-1/+1
| | | | | solution) in the same way as listobject.c got changed. Hoping for a better solution.
* Merge the tim-obmalloc branch to the trunk.Tim Peters2006-03-161-205/+525
| | | | | | | This is a heavily altered derivative of SF patch 1123430, Evan Jones's heroic effort to make obmalloc return unused arenas to the system free(), with some heuristic strategies to make it more likley that arenas eventually _can_ be freed.
* Oops, this is supposed to be disabled by default.Neal Norwitz2006-02-161-1/+1
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-4/+7
|
* Do a better job of not inlining Py_ADDRESS_IN_RANGE() for newer gcc's.Neal Norwitz2005-11-131-2/+9
| | | | Perhaps Py_NO_INLINE should be moved to pyport.h or some other header?
* SF bug 1185883: PyObject_Realloc can't safely take over a block currentlyTim Peters2005-07-101-27/+23
| | | | | | | | | | managed by C, because it's possible for the block to be smaller than the new requested size, and at the end of allocated VM. Trying to copy over nbytes bytes to a Python small-object block can segfault then, and there's no portable way to avoid this (we would have to know how many bytes starting at p are addressable, and std C has no means to determine that). Bugfix candidate. Should be backported to 2.4, but I'm out of time.
* whoops, I wanted that commented out by default, will add doc to MiscNeal Norwitz2004-06-061-1/+1
|
* SF bug 881641, make it easier to use valgrindNeal Norwitz2004-06-061-4/+39
|
* Whitespace normalization.Walter Dörwald2003-06-171-6/+6
|
* Remove MALLOC_ZERO_RETURNS_NULL.Martin v. Löwis2002-11-231-2/+0
|
* Patch #627105: Document that SYSTEM_PAGE_SIZE really should not beMartin v. Löwis2002-10-261-1/+4
| | | | larger than the system page size.
* Fix warnings on 64-bit platforms about casts from pointers to ints.Guido van Rossum2002-09-121-1/+1
| | | | Two of these were real bugs.
* Remove extraneous semicolon.Jeremy Hylton2002-07-181-1/+1
| | | | (Silences compiler warning for Compaq C++ 6.5 on Tru64.)
* Documented PYMALLOC_DEBUG. This completes primary coverage of all theTim Peters2002-07-101-1/+1
| | | | | "special builds" I ever use. If you use others, document them here, or don't be surprised if I rip out the code for them <0.5 wink>.
* PyObject_Realloc(): If a small block is shrinking, bite the expense ofTim Peters2002-05-021-5/+16
| | | | copying it if at least 25% of the input block can be reclaimed.
* _PyObject_DebugCheckAddress(): If the leading pad bytes are corrupt,Tim Peters2002-04-281-18/+25
| | | | | display a msg warning that the count of bytes requested may be bogus, and that a segfault may happen next.
* _PyObject_DebugMallocStats(): Added some potentially expensive internalTim Peters2002-04-181-5/+41
| | | | | | consistency checks, enabled only in a debug (Py_DEBUG) build. Note that this never gets called automatically unless PYMALLOC_DEBUG is #define'd too, and the envar PYTHONMALLOCSTATS exists.
* PyObject_Malloc: make a tiny bit faster for platforms where malloc(0)Tim Peters2002-04-181-2/+9
| | | | | | doesn't return NULL. PyObject_Realloc: better comment for why we don't call PyObject_Malloc(0).
* Remove some long-disabled debugging boilerplate.Tim Peters2002-04-181-26/+0
|
* _PyObject_DebugDumpStats: renamed to _PyObject_DebugMallocStats.Tim Peters2002-04-131-4/+8
| | | | | | Added code to call this when PYMALLOC_DEBUG is enabled, and envar PYTHONMALLOCSTATS is set, whenever a new arena is obtained and once late in the Python shutdown process.
* Small anal correctness tweaks:Tim Peters2002-04-121-2/+2
| | | | | | | | | | _PyObject_DebugMalloc: explicitly cast PyObject_Malloc's result to the target pointer type. _PyObject_DebugDumpStats: change decl of arena_alignment from unsigned int to unsigned long. This is for the 2.3 release only (it's new code).
* _PyObject_DebugRealloc(): rewritten to let the underlying realloc doTim Peters2002-04-121-27/+30
| | | | | | | | | | most of the work. In particular, if the underlying realloc is able to grow the memory block in place, great (this routine used to do a fresh malloc + memcpy every time a block grew). BTW, I'm not so keen here on avoiding possible quadratic-time realloc patterns as I am on making the debug pymalloc more invisible (the more it uses memory "just like" the underlying allocator, the better the chance that a suspected memory corruption bug won't vanish when the debug malloc is turned on).
* _PyObject_DebugDumpAddress(): clarify an output message.Tim Peters2002-04-121-1/+1
|
* PYMALLOC_{CLEAN, DEAD, FORBIDDEN}BYTE symbols: remove the PYMALLOC_Tim Peters2002-04-121-34/+39
| | | | | prefix. These symbols are private to the file, and the PYMALLOC_ gets in the way (overly long code lines, comments, and error messages).
* Move PyObject_Malloc and PyObject_Free here from object.c. RemoveNeil Schemenauer2002-04-121-61/+33
| | | | | PyMalloc_ prefix and use PyObject_ instead. I'm not sure about the debugging functions. Perhaps they should stay as PyMalloc_.
* SF bug 542181: Realloc behaviorTim Peters2002-04-111-12/+16
| | | | | | | | | | | The bug report pointed out a bogosity in the comment block explaining thread safety for arena management. Repaired that comment, repaired a couple others while I was at it, and added an assert. _PyMalloc_DebugRealloc: If this needed to get more memory, but couldn't, it erroneously freed the original memory. Repaired that. This is for 2.3 only (unless we decide to backport the new pymalloc).
* Minor improvements to the stats output dump, including adding commas toTim Peters2002-04-061-10/+34
| | | | the big numbers.
* Repair an incomprehensible comment.Tim Peters2002-04-051-2/+2
|
* _PyMalloc_DebugDumpStats(): vastly improved the output, and it nowTim Peters2002-04-051-21/+58
| | | | accounts for every byte.
* Widespread, but mostly in _PyMalloc_Malloc: optimize away all expensiveTim Peters2002-04-051-40/+39
| | | | | | | | runtime multiplications and divisions, via the scheme developed with Vladimir Marangozov on Python-Dev. The pool_header struct loses its capacity member, but gains nextoffset and maxnextoffset members; this still leaves it at 32 bytes on a 32-bit box (it has to be padded to a multiple of 8 bytes).
* _PyMalloc_Realloc(): removed a now-pointless cast.Tim Peters2002-04-041-1/+1
|
* _PyMalloc_{Malloc, Realloc}: Strive to meet the doc's promises aboutTim Peters2002-04-041-42/+44
| | | | | | | | | | | | | | | | | | | what these do given a 0 size argument. This is so that when pymalloc is enabled, we don't need to wrap pymalloc calls in goofy little routines special-casing 0. Note that it's virtually impossible to meet the doc's promise that malloc(0) will never return NULL; this makes a best effort, but not an insane effort. The code does promise that realloc(not-NULL, 0) will never return NULL (malloc(0) is much harder). _PyMalloc_Realloc: Changed to take over all requests for 0 bytes, and rearranged to be a little quicker in expected cases. All over the place: when resorting to the platform allocator, call free/malloc/realloc directly, without indirecting thru macros. This should avoid needing a nightmarish pile of #ifdef-ery if PYMALLOC_DEBUG is changed so that pymalloc takes over all Py(Mem, Object} memory operations (which would add useful debugging info to PyMem_xyz allocations too).
* Fixed errors in two comments.Tim Peters2002-04-011-3/+4
|
* Restructured my pool-management overview in terms of the threeTim Peters2002-04-011-21/+61
| | | | | | | | | | | | | possible pool states. I think it's much clearer now. Added a new long overdue block-management overview comment block. I believe the comments are in good shape now. Added two comments about possible small optimizations (one getting rid of runtime multiplications at the cost of a new pool_header member; the other getting rid of runtime divisions and the pool_header capacity member, at the cost of a static const vector of 32 uints).
* New PYMALLOC_DEBUG function void _PyMalloc_DebugDumpStats(void).Tim Peters2002-04-011-1/+97
| | | | | | | | | | | | | This displays stats about the # of arenas, pools, blocks and bytes, to stderr, both used and reserved but unused. CAUTION: Because PYMALLOC_DEBUG is on, the debug malloc routine adds 16 bytes to each request. This makes each block appear two size classes higher than it would be if PYMALLOC_DEBUG weren't on. So far, playing with this confirms the obvious: there's a lot of activity in the "small dict" size class, but nothing in the core makes any use of the 8-byte or 16-byte classes.
* Add one more assert that indirectly interlocking conditions are consistentTim Peters2002-03-311-0/+1
| | | | with each other.
* Fixed an error in a new assert.Tim Peters2002-03-311-1/+1
|
* Fixed a typo in a new comment.Tim Peters2002-03-311-1/+1
|
* _PyMalloc_Free(): As was already done for _PyMalloc_Malloc, rearrangedTim Peters2002-03-311-37/+47
| | | | | | | | | | the code so that the most frequent cases come first. Added comments. Found a hidden assumption that a pool contains room for at least two blocks, and added an assert to catch a violation if it ever happens in a place where that matters. Gave the normal "I allocated this block" case a longer basic block to work with before it has to do its first branch (via breaking apart an embedded assignment in an "if", and hoisting common code out of both branches).
* Added a long-overdue comment block giving an overview of pool operationsTim Peters2002-03-311-3/+60
| | | | and terminology, plus explanation of some extreme obscurities.