summaryrefslogtreecommitdiffstats
path: root/Objects/obmalloc.c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* It's once again thought safe to call the pymalloc free/realloc with anTim Peters2002-03-301-14/+27
| | | | | | | | | | | | | | | | | | | address obtained from system malloc/realloc without holding the GIL. When the vector of arena base addresses has to grow, the old vector is deliberately leaked. This makes "stale" x-thread references safe. arenas and narenas are also declared volatile, and changed in an order that prevents a thread from picking up a value of narenas too large for the value of arenas it sees. Added more asserts. Fixed an old inaccurate comment. Added a comment explaining why it's safe to call pymalloc free/realloc with an address obtained from system malloc/realloc even when arenas is still NULL (this is obscure, since the ADDRESS_IN_RANGE macro appears <wink> to index into arenas).
* new_arena(): In error cases, reset the number of available pools to 0.Tim Peters2002-03-301-0/+1
| | | | Else the pymalloc malloc will go insane the next time it's called.
* Changed the #-of-arenas counters to uints -- no need to be insane aboutTim Peters2002-03-301-10/+11
| | | | | | | this. But added an overflow check just in case there is. Got rid of the ushort macro. It wasn't used anymore (it was only used in the no-longer-exists off_t macro), and there's no plausible use for it.
* Turns out the off_t macro isn't used anymore, so got rid of it.Tim Peters2002-03-301-3/+0
|
* Now that we're no longer linking arenas together, there's no need toTim Peters2002-03-301-25/+21
| | | | | | | | | | | | | | | | | | | | | | waste the first pool if malloc happens to return a pool-aligned address. This means the number of pools per arena can now vary by 1. Unfortunately, the code counted up from 0 to a presumed constant number of pools. So changed the increasing "watermark" counter to a decreasing "nfreepools" counter instead, and fiddled various stuff accordingly. This also allowed getting rid of two more macros. Also changed the code to align the first address to a pool boundary instead of a page boundary. These are two parallel sets of macro #defines that happen to be identical now, but the page macros are in theory more restrictive (bigger), and there's simply no reason I can see that it wasn't aligning to the less restrictive pool size all along (the code only relies on pool alignment). Hmm. The "page size" macros aren't used for anything *except* defining the pool size macros, and the comments claim the latter isn't necessary. So this has the feel of a layer of indirection that doesn't serve a purpose; should probably get rid of the page macros now.
* Retract the claim that this is always safe if PyMem_{Del, DEL, Free, FREE}Tim Peters2002-03-301-0/+4
| | | | | | | are called without the GIL. It's incredibly unlikely to fail, but I can't make this bulletproof without either adding a lock for exclusion, or giving up on growing the arena base-address vector (it would be safe if this were a static array).
* Lots of changes:Tim Peters2002-03-301-127/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + A new scheme for determining whether an address belongs to a pymalloc arena. This should be 100% reliable. The poolp->pooladdr and poolp->magic members are gone. A new poolp->arenaindex member takes their place. Note that the pool header overhead doesn't actually shrink, though, since the header is padded to a multiple of 8 bytes. + _PyMalloc_Free and _PyMalloc_Realloc should now be safe to call for any legit address, whether obtained from a _PyMalloc function or from the system malloc/realloc. It should even be safe to call _PyMalloc_Free when *not* holding the GIL, provided that the passed-in address was obtained from system malloc/realloc. Since this is accomplished without any locks, you better believe the code is subtle. I hope it's sufficiently commented. + The above implies we don't need the new PyMalloc_{New, NewVar, Del} API anymore, and could switch back to PyObject_XXX without breaking existing code mixing PyObject_XXX with PyMem_{Del, DEL, Free, FREE}. Nothing is done here about that yet, and I'd like to see this new code exercised more first. + The small object threshhold is boosted to 256 (the max). We should play with that some more, but the old 64 was way too small for 2.3. + Getting a new arena is now done via new function new_arena(). + Removed some unused macros, and squashed out some macros that were used only once to define other macros. + Arenas are no longer linked together. A new vector of arena base addresses had to be created anyway to make address classification bulletproof. + A lot of the patch size is an illusion: given the way address classification works now, it was more convenient to switch the sense of the prime "if" tests in the realloc and free functions, so the "if" and "else" blocks got swapped. + Assorted minor code, comment and whitespace cleanup. Back to the Windows installer <wink>.
* Add missing "void" to function.Neil Schemenauer2002-03-281-1/+1
|
* PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhereTim Peters2002-03-281-62/+34
| | | | | fast, and just cluttered the code. Get rid of it for now. If a compelling case can be made for it, easy to restore it later.
* _PyMalloc_DebugRealloc(): simplify decl of "fresh".Tim Peters2002-03-241-5/+15
| | | | | | Assorted: bump the serial number via a trivial new bumpserialno() function. The point is to give a single place to set a breakpoint when waiting for a specific serial number.
* Minor code cleanup -- no semantic changes.Tim Peters2002-03-231-22/+28
|
* Give Python a debug-mode pymalloc, much as sketched on Python-Dev.Tim Peters2002-03-231-17/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug allocator. This can be done independent of build type (release or debug). A debug build automatically defines PYMALLOC_DEBUG when pymalloc is enabled. It's a detected error to define PYMALLOC_DEBUG when pymalloc isn't enabled. Two debugging entry points defined only under PYMALLOC_DEBUG: + _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb) to sanity-check a memory block obtained from pymalloc. It sprays info to stderr (see next) and dies via Py_FatalError if the block is detectably damaged. + _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info about a debug memory block to stderr. A tiny start at implementing "API family" checks isn't good for anything yet. _PyMalloc_DebugRealloc() has been optimized to do little when the new size is <= old size. However, if the new size is larger, it really can't call the underlying realloc() routine without either violating its contract, or knowing something non-trivial about how the underlying realloc() works. A memcpy is always done in this case. This was a disaster for (and only) one of the std tests: test_bufio creates single text file lines up to a million characters long. On Windows, fileobject.c's get_line() uses the horridly funky getline_via_fgets(), which keeps growing and growing a string object hoping to find a newline. It grew the string object 1000 bytes each time, so for a million-character string it took approximately forever (I gave up after a few minutes). So, also: fileobject.c, getline_via_fgets(): When a single line is outrageously long, grow the string object at a mildly exponential rate, instead of just 1000 bytes at a time. That's enough so that a debug-build test_bufio finishes in about 5 seconds on my Win98SE box. I'm curious to try this on Win2K, because it has very different memory behavior than Win9X, and test_bufio always took a factor of 10 longer to complete on Win2K. It *could* be that the endless reallocs were simply killing it on Win2K even in the release build.
* Just whitespace fiddling.Tim Peters2002-03-231-10/+10
|
* Build obmalloc.c directly instead of #include'ing from object.c.Tim Peters2002-03-231-0/+50
| | | | | | | | Also move all _PyMalloc_XXX entry points into obmalloc.c. The Windows build works fine. The Unix build is changed here (Makefile.pre.in), but not tested. No other platform's build process has been fiddled.
* Remove malloc hooks.Neil Schemenauer2002-03-221-69/+0
|
* Drop the PyCore_* memory API.Neil Schemenauer2002-03-181-21/+21
|
* Simpilify PyCore_* macros by assuming the function prototypes forNeil Schemenauer2002-03-181-57/+21
| | | | malloc() and free() don't change.
* Identifiers matching _[A-Z_]\w* are reserved for C implementations.Tim Peters2001-03-111-6/+6
| | | | | | May or may not be related to bug 407680 (obmalloc.c - looks like it's corrupted). This repairs the illegal vrbl names, but leaves a pile of illegal macro names (_THIS_xxx, _SYSTEM_xxx, _SET_HOOKS, _FETCH_HOOKS).
* Add Vladimir Marangozov's object allocator. It is disabled by default. ThisNeil Schemenauer2001-02-271-0/+743
closes SF patch #401229.
generated by cgit v0.12 at 2025-08-27 20:28:58 (GMT)