traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
cpython/Objects/obmalloc.c

1077 lines
32 KiB
C
Raw Normal View History

Build obmalloc.c directly instead of #include'ing from object.c. 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.
2002-03-22 20:20:15 -04:00
#include "Python.h"
#ifdef WITH_PYMALLOC
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/* An object allocator for Python.
Here is an introduction to the layers of the Python memory architecture,
showing where the object allocator is actually used (layer +2), It is
called for every object allocation and deallocation (PyObject_New/Del),
unless the object-specific allocators implement a proprietary allocation
scheme (ex.: ints use a simple free list). This is also the place where
the cyclic garbage collector operates selectively on container objects.
Object-specific allocators
_____ ______ ______ ________
[ int ] [ dict ] [ list ] ... [ string ] Python core |
+3 | <----- Object-specific memory -----> | <-- Non-object memory --> |
_______________________________ | |
[ Python's object allocator ] | |
+2 | ####### Object memory ####### | <------ Internal buffers ------> |
______________________________________________________________ |
[ Python's raw memory allocator (PyMem_ API) ] |
+1 | <----- Python memory (under PyMem manager's control) ------> | |
__________________________________________________________________
[ Underlying general-purpose allocator (ex: C library malloc) ]
0 | <------ Virtual memory allocated for the python process -------> |
=========================================================================
_______________________________________________________________________
[ OS-specific Virtual Memory Manager (VMM) ]
-1 | <--- Kernel dynamic storage allocation & management (page-based) ---> |
__________________________________ __________________________________
[ ] [ ]
-2 | <-- Physical memory: ROM/RAM --> | | <-- Secondary storage (swap) --> |
*/
/*==========================================================================*/
/* A fast, special-purpose memory allocator for small blocks, to be used
on top of a general-purpose malloc -- heavily based on previous art. */
/* Vladimir Marangozov -- August 2000 */
/*
* "Memory management is where the rubber meets the road -- if we do the wrong
* thing at any level, the results will not be good. And if we don't make the
* levels work well together, we are in serious trouble." (1)
*
* (1) Paul R. Wilson, Mark S. Johnstone, Michael Neely, and David Boles,
* "Dynamic Storage Allocation: A Survey and Critical Review",
* in Proc. 1995 Int'l. Workshop on Memory Management, September 1995.
*/
/* #undef WITH_MEMORY_LIMITS */ /* disable mem limit checks */
/*==========================================================================*/
/*
* Allocation strategy abstract:
*
* For small requests, the allocator sub-allocates <Big> blocks of memory.
* Requests greater than 256 bytes are routed to the system's allocator.
Just whitespace fiddling.
2002-03-22 20:28:57 -04:00
*
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
* Small requests are grouped in size classes spaced 8 bytes apart, due
* to the required valid alignment of the returned address. Requests of
* a particular size are serviced from memory pools of 4K (one VMM page).
* Pools are fragmented on demand and contain free lists of blocks of one
* particular size class. In other words, there is a fixed-size allocator
* for each size class. Free pools are shared by the different allocators
* thus minimizing the space reserved for a particular size class.
*
* This allocation strategy is a variant of what is known as "simple
* segregated storage based on array of free lists". The main drawback of
* simple segregated storage is that we might end up with lot of reserved
* memory for the different free lists, which degenerate in time. To avoid
* this, we partition each free list in pools and we share dynamically the
* reserved space between all free lists. This technique is quite efficient
* for memory intensive programs which allocate mainly small-sized blocks.
*
* For small requests we have the following table:
*
* Request in bytes Size of allocated block Size class idx
* ----------------------------------------------------------------
* 1-8 8 0
* 9-16 16 1
* 17-24 24 2
* 25-32 32 3
* 33-40 40 4
* 41-48 48 5
* 49-56 56 6
* 57-64 64 7
* 65-72 72 8
* ... ... ...
* 241-248 248 30
* 249-256 256 31
Just whitespace fiddling.
2002-03-22 20:28:57 -04:00
*
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
* 0, 257 and up: routed to the underlying allocator.
*/
/*==========================================================================*/
/*
* -- Main tunable settings section --
*/
/*
* Alignment of addresses returned to the user. 8-bytes alignment works
* on most current architectures (with 32-bit or 64-bit address busses).
* The alignment value is also used for grouping small requests in size
* classes spaced ALIGNMENT bytes apart.
*
* You shouldn't change this unless you know what you are doing.
*/
#define ALIGNMENT 8 /* must be 2^N */
#define ALIGNMENT_SHIFT 3
#define ALIGNMENT_MASK (ALIGNMENT - 1)
/*
* Max size threshold below which malloc requests are considered to be
* small enough in order to use preallocated memory pools. You can tune
* this value according to your application behaviour and memory needs.
*
* The following invariants must hold:
* 1) ALIGNMENT <= SMALL_REQUEST_THRESHOLD <= 256
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
* 2) SMALL_REQUEST_THRESHOLD is evenly divisible by ALIGNMENT
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
*
* Although not required, for better performance and space efficiency,
* it is recommended that SMALL_REQUEST_THRESHOLD is set to a power of 2.
*/
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
#define SMALL_REQUEST_THRESHOLD 256
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
#define NB_SMALL_SIZE_CLASSES (SMALL_REQUEST_THRESHOLD / ALIGNMENT)
/*
* The system's VMM page size can be obtained on most unices with a
* getpagesize() call or deduced from various header files. To make
* things simpler, we assume that it is 4K, which is OK for most systems.
* It is probably better if this is the native page size, but it doesn't
* have to be.
*/
#define SYSTEM_PAGE_SIZE (4 * 1024)
#define SYSTEM_PAGE_SIZE_MASK (SYSTEM_PAGE_SIZE - 1)
/*
* Maximum amount of memory managed by the allocator for small requests.
*/
#ifdef WITH_MEMORY_LIMITS
#ifndef SMALL_MEMORY_LIMIT
#define SMALL_MEMORY_LIMIT (64 * 1024 * 1024) /* 64 MB -- more? */
#endif
#endif
/*
* The allocator sub-allocates <Big> blocks of memory (called arenas) aligned
* on a page boundary. This is a reserved virtual address space for the
* current process (obtained through a malloc call). In no way this means
* that the memory arenas will be used entirely. A malloc(<Big>) is usually
* an address range reservation for <Big> bytes, unless all pages within this
* space are referenced subsequently. So malloc'ing big blocks and not using
* them does not mean "wasting memory". It's an addressable range wastage...
*
* Therefore, allocating arenas with malloc is not optimal, because there is
* some address space wastage, but this is the most portable way to request
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
* memory from the system across various platforms.
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
*/
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/* ALLOCATED_ARENA_SIZE is passed to malloc; after alignment, we can't
* count on more than ARENA_SIZE bytes being usable for pools.
*/
#define ALLOCATED_ARENA_SIZE (256 << 10) /* 256KB */
#define ARENA_SIZE (ALLOCATED_ARENA_SIZE - SYSTEM_PAGE_SIZE)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
#ifdef WITH_MEMORY_LIMITS
#define MAX_ARENAS (SMALL_MEMORY_LIMIT / ARENA_SIZE)
#endif
/*
* Size of the pools used for small blocks. Should be a power of 2,
* between 1K and SYSTEM_PAGE_SIZE, that is: 1k, 2k, 4k, eventually 8k.
*/
#define POOL_SIZE SYSTEM_PAGE_SIZE /* must be 2^N */
#define POOL_SIZE_MASK SYSTEM_PAGE_SIZE_MASK
#define ARENA_NB_POOLS (ARENA_SIZE / POOL_SIZE)
/*
* -- End of tunable settings section --
*/
/*==========================================================================*/
/*
* Locking
*
* To reduce lock contention, it would probably be better to refine the
* crude function locking with per size class locking. I'm not positive
* however, whether it's worth switching to such locking policy because
* of the performance penalty it might introduce.
*
* The following macros describe the simplest (should also be the fastest)
* lock object on a particular platform and the init/fini/lock/unlock
* operations on it. The locks defined here are not expected to be recursive
* because it is assumed that they will always be called in the order:
* INIT, [LOCK, UNLOCK]*, FINI.
*/
/*
* Python's threads are serialized, so object malloc locking is disabled.
*/
#define SIMPLELOCK_DECL(lock) /* simple lock declaration */
#define SIMPLELOCK_INIT(lock) /* allocate (if needed) and initialize */
#define SIMPLELOCK_FINI(lock) /* free/destroy an existing lock */
#define SIMPLELOCK_LOCK(lock) /* acquire released lock */
#define SIMPLELOCK_UNLOCK(lock) /* release acquired lock */
/*
* Basic types
* I don't care if these are defined in <sys/types.h> or elsewhere. Axiom.
*/
#undef uchar
#define uchar unsigned char /* assuming == 8 bits */
#undef ushort
#define ushort unsigned short /* assuming >= 16 bits */
#undef uint
#define uint unsigned int /* assuming >= 16 bits */
#undef ulong
#define ulong unsigned long /* assuming >= 32 bits */
#undef off_t
#define off_t uint /* 16 bits <= off_t <= 64 bits */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
#undef uptr
#define uptr Py_uintptr_t
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/* When you say memory, my mind reasons in terms of (pointers to) blocks */
typedef uchar block;
/* Pool for small blocks */
struct pool_header {
Identifiers matching _[A-Z_]\w* are reserved for C implementations. 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).
2001-03-11 14:36:13 -04:00
union { block *_padding;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
uint count; } ref; /* number of allocated blocks */
block *freeblock; /* pool's free list head */
struct pool_header *nextpool; /* next pool of this size class */
struct pool_header *prevpool; /* previous pool "" */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
ulong arenaindex; /* index into arenas of base adr */
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
uint szidx; /* block size class index */
uint capacity; /* pool capacity in # of blocks */
};
typedef struct pool_header *poolp;
#undef ROUNDUP
#define ROUNDUP(x) (((x) + ALIGNMENT_MASK) & ~ALIGNMENT_MASK)
#define POOL_OVERHEAD ROUNDUP(sizeof(struct pool_header))
#define DUMMY_SIZE_IDX 0xffff /* size class of newly cached pools */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/* Round pointer P down to the closest pool-aligned address <= P, as a poolp */
#define POOL_ADDR(P) \
((poolp)((uptr)(P) & ~(uptr)POOL_SIZE_MASK))
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*==========================================================================*/
/*
* This malloc lock
*/
Identifiers matching _[A-Z_]\w* are reserved for C implementations. 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).
2001-03-11 14:36:13 -04:00
SIMPLELOCK_DECL(_malloc_lock);
#define LOCK() SIMPLELOCK_LOCK(_malloc_lock)
#define UNLOCK() SIMPLELOCK_UNLOCK(_malloc_lock)
#define LOCK_INIT() SIMPLELOCK_INIT(_malloc_lock)
#define LOCK_FINI() SIMPLELOCK_FINI(_malloc_lock)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*
* Pool table -- doubly linked lists of partially used pools
*/
#define PTA(x) ((poolp )((uchar *)&(usedpools[2*(x)]) - 2*sizeof(block *)))
#define PT(x) PTA(x), PTA(x)
static poolp usedpools[2 * ((NB_SMALL_SIZE_CLASSES + 7) / 8) * 8] = {
PT(0), PT(1), PT(2), PT(3), PT(4), PT(5), PT(6), PT(7)
#if NB_SMALL_SIZE_CLASSES > 8
, PT(8), PT(9), PT(10), PT(11), PT(12), PT(13), PT(14), PT(15)
#if NB_SMALL_SIZE_CLASSES > 16
, PT(16), PT(17), PT(18), PT(19), PT(20), PT(21), PT(22), PT(23)
#if NB_SMALL_SIZE_CLASSES > 24
, PT(24), PT(25), PT(26), PT(27), PT(28), PT(29), PT(30), PT(31)
#if NB_SMALL_SIZE_CLASSES > 32
, PT(32), PT(33), PT(34), PT(35), PT(36), PT(37), PT(38), PT(39)
#if NB_SMALL_SIZE_CLASSES > 40
, PT(40), PT(41), PT(42), PT(43), PT(44), PT(45), PT(46), PT(47)
#if NB_SMALL_SIZE_CLASSES > 48
, PT(48), PT(49), PT(50), PT(51), PT(52), PT(53), PT(54), PT(55)
#if NB_SMALL_SIZE_CLASSES > 56
, PT(56), PT(57), PT(58), PT(59), PT(60), PT(61), PT(62), PT(63)
#endif /* NB_SMALL_SIZE_CLASSES > 56 */
#endif /* NB_SMALL_SIZE_CLASSES > 48 */
#endif /* NB_SMALL_SIZE_CLASSES > 40 */
#endif /* NB_SMALL_SIZE_CLASSES > 32 */
#endif /* NB_SMALL_SIZE_CLASSES > 24 */
#endif /* NB_SMALL_SIZE_CLASSES > 16 */
#endif /* NB_SMALL_SIZE_CLASSES > 8 */
};
/*
* Free (cached) pools
*/
static poolp freepools = NULL; /* free list for cached pools */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/*==========================================================================*/
/* Arena management. */
/* arenas is a vector of arena base addresses, in order of allocation time.
* arenas currently contains narenas entries, and has space allocated
* for at most maxarenas entries.
*
* CAUTION: See the long comment block about thread safety in new_arena():
* the code currently relies in deep ways on that this vector only grows,
* and only grows by appending at the end. For now we never return an arena
* to the OS.
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
*/
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
static uptr *arenas = NULL;
static ulong narenas = 0;
static ulong maxarenas = 0;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/* Number of pools already allocated from the current arena. This is
* initialized to the max # of pools to provoke the first allocation request
* into allocating a new arena.
*/
static uint watermark = ARENA_NB_POOLS;
/* Free space start address in current arena. */
static block *arenabase = NULL;
#if 0
static ulong wasmine = 0;
static ulong wasntmine = 0;
static void
dumpem(void *ptr)
{
if (ptr)
printf("inserted new arena at %08x\n", ptr);
printf("# arenas %d\n", narenas);
printf("was mine %lu wasn't mine %lu\n", wasmine, wasntmine);
}
#define INCMINE ++wasmine
#define INCTHEIRS ++wasntmine
#else
#define dumpem(ptr)
#define INCMINE
#define INCTHEIRS
#endif
/* Allocate a new arena and return its base address. If we run out of
* memory, return NULL.
*/
static block *
new_arena(void)
{
block *bp = (block *)PyMem_MALLOC(ALLOCATED_ARENA_SIZE);
if (bp == NULL)
return NULL;
watermark = 0;
/* Page-round up */
arenabase = bp + (SYSTEM_PAGE_SIZE -
((off_t )bp & SYSTEM_PAGE_SIZE_MASK));
/* Make room for a new entry in the arenas vector. */
if (arenas == NULL) {
arenas = (uptr *)PyMem_MALLOC(16 * sizeof(*arenas));
if (arenas == NULL)
goto error;
maxarenas = 16;
narenas = 0;
}
else if (narenas == maxarenas) {
/* Grow arenas. Don't use realloc: if this fails, we
* don't want to lose the base addresses we already have.
* Exceedingly subtle: Someone may be calling the pymalloc
* free via PyMem_{DEL, Del, FREE, Free} without holding the
*.GIL. Someone else may simultaneously be calling the
* pymalloc malloc while holding the GIL via, e.g.,
* PyObject_New. Now the pymalloc free may index into arenas
* for an address check, while the pymalloc malloc calls
* new_arena and we end up here to grow a new arena *and*
* grow the arenas vector. If the value for arenas pymalloc
* free picks up "vanishes" during this resize, anything may
* happen, and it would be an incredibly rare bug. Therefore
* the code here takes great pains to make sure that, at every
* moment, arenas always points to an intact vector of
* addresses. It doesn't matter whether arenas points to a
* wholly up-to-date vector when pymalloc free checks it in
* this case, because the only legal (and that even this is
* legal is debatable) way to call PyMem_{Del, etc} while not
* holding the GIL is if the memory being released is not
* object memory, i.e. if the address check in pymalloc free
* is supposed to fail. Having an incomplete vector can't
* make a supposed-to-fail case succeed by mistake (it could
* only make a supposed-to-succeed case fail by mistake).
* Read the above 50 times before changing anything in this
* block.
Retract the claim that this is always safe if PyMem_{Del, DEL, Free, FREE} 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).
2002-03-30 02:20:23 -04:00
* XXX Fudge. This is still vulnerable: there's nothing
* XXX to stop the bad-guy thread from picking up the
* XXX current value of arenas, but not indexing off of it
* XXX until after the PyMem_FREE(oldarenas) below completes.
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
*/
uptr *oldarenas;
int newmax = maxarenas + (maxarenas >> 1);
uptr *p = (uptr *)PyMem_MALLOC(newmax * sizeof(*arenas));
if (p == NULL)
goto error;
memcpy(p, arenas, narenas * sizeof(*arenas));
oldarenas = arenas;
arenas = p;
PyMem_FREE(oldarenas);
maxarenas = newmax;
}
/* Append the new arena address to arenas. */
assert(narenas < maxarenas);
arenas[narenas] = (uptr)bp;
++narenas;
dumpem(bp);
return bp;
error:
PyMem_FREE(bp);
return NULL;
}
/* Return true if and only if P is an address that was allocated by
* pymalloc. I must be the index into arenas that the address claims
* to come from.
* Tricky: Letting B be the arena base address in arenas[I], P belongs to the
* arena if and only if
* B <= P < B + ALLOCATED_ARENA_SIZE
* Subtracting B throughout, this is true iff
* 0 <= P-B < ALLOCATED_ARENA_SIZE
* By using unsigned arithmetic, the "0 <=" half of the test can be skipped.
*/
#define ADDRESS_IN_RANGE(P, I) \
((I) < narenas && (uptr)(P) - arenas[I] < (uptr)ALLOCATED_ARENA_SIZE)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*==========================================================================*/
/* malloc */
/*
* The basic blocks are ordered by decreasing execution frequency,
* which minimizes the number of jumps in the most common cases,
* improves branching prediction and instruction scheduling (small
* block allocations typically result in a couple of instructions).
* Unless the optimizer reorders everything, being too smart...
*/
void *
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
_PyMalloc_Malloc(size_t nbytes)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
{
block *bp;
poolp pool;
poolp next;
uint size;
/*
* This implicitly redirects malloc(0)
*/
if ((nbytes - 1) < SMALL_REQUEST_THRESHOLD) {
LOCK();
/*
* Most frequent paths first
*/
size = (uint )(nbytes - 1) >> ALIGNMENT_SHIFT;
pool = usedpools[size + size];
if (pool != pool->nextpool) {
/*
* There is a used pool for this size class.
* Pick up the head block of its free list.
*/
++pool->ref.count;
bp = pool->freeblock;
if ((pool->freeblock = *(block **)bp) != NULL) {
UNLOCK();
return (void *)bp;
}
/*
* Reached the end of the free list, try to extend it
*/
if (pool->ref.count < pool->capacity) {
/*
* There is room for another block
*/
size++;
size <<= ALIGNMENT_SHIFT; /* block size */
pool->freeblock = (block *)pool + \
POOL_OVERHEAD + \
pool->ref.count * size;
*(block **)(pool->freeblock) = NULL;
UNLOCK();
return (void *)bp;
}
/*
* Pool is full, unlink from used pools
*/
next = pool->nextpool;
pool = pool->prevpool;
next->prevpool = pool;
pool->nextpool = next;
UNLOCK();
return (void *)bp;
}
/*
* Try to get a cached free pool
*/
pool = freepools;
if (pool != NULL) {
/*
* Unlink from cached pools
*/
freepools = pool->nextpool;
init_pool:
/*
* Frontlink to used pools
*/
next = usedpools[size + size]; /* == prev */
pool->nextpool = next;
pool->prevpool = next;
next->nextpool = pool;
next->prevpool = pool;
pool->ref.count = 1;
if (pool->szidx == size) {
/*
* Luckily, this pool last contained blocks
* of the same size class, so its header
* and free list are already initialized.
*/
bp = pool->freeblock;
pool->freeblock = *(block **)bp;
UNLOCK();
return (void *)bp;
}
/*
* Initialize the pool header and free list
* then return the first block.
*/
pool->szidx = size;
size++;
size <<= ALIGNMENT_SHIFT; /* block size */
bp = (block *)pool + POOL_OVERHEAD;
pool->freeblock = bp + size;
*(block **)(pool->freeblock) = NULL;
pool->capacity = (POOL_SIZE - POOL_OVERHEAD) / size;
UNLOCK();
return (void *)bp;
}
/*
* Allocate new pool
*/
if (watermark < ARENA_NB_POOLS) {
/* commit malloc(POOL_SIZE) from the current arena */
commit_pool:
watermark++;
pool = (poolp )arenabase;
arenabase += POOL_SIZE;
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
pool->arenaindex = narenas - 1;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
pool->szidx = DUMMY_SIZE_IDX;
goto init_pool;
}
/*
* Allocate new arena
*/
#ifdef WITH_MEMORY_LIMITS
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
if (!(narenas < MAX_ARENAS)) {
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
UNLOCK();
goto redirect;
}
#endif
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
bp = new_arena();
if (bp != NULL)
goto commit_pool;
UNLOCK();
goto redirect;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
}
/* The small block allocator ends here. */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
redirect:
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*
* Redirect the original request to the underlying (libc) allocator.
* We jump here on bigger requests, on error in the code above (as a
* last chance to serve the request) or when the max memory limit
* has been reached.
*/
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
return (void *)PyMem_MALLOC(nbytes);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
}
/* free */
void
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
_PyMalloc_Free(void *p)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
{
poolp pool;
poolp next, prev;
uint size;
if (p == NULL) /* free(NULL) has no effect */
return;
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
pool = POOL_ADDR(p);
if (ADDRESS_IN_RANGE(p, pool->arenaindex)) {
/* We allocated this address. */
INCMINE;
LOCK();
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
* At this point, the pool is not empty
*/
if ((*(block **)p = pool->freeblock) == NULL) {
/*
* Pool was full
*/
pool->freeblock = (block *)p;
--pool->ref.count;
/*
* Frontlink to used pools
* This mimics LRU pool usage for new allocations and
* targets optimal filling when several pools contain
* blocks of the same size class.
*/
size = pool->szidx;
next = usedpools[size + size];
prev = next->prevpool;
pool->nextpool = next;
pool->prevpool = prev;
next->prevpool = pool;
prev->nextpool = pool;
UNLOCK();
return;
}
/*
* Pool was not full
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
*/
pool->freeblock = (block *)p;
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
if (--pool->ref.count != 0) {
UNLOCK();
return;
}
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/*
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
* Pool is now empty, unlink from used pools
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
*/
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
next = pool->nextpool;
prev = pool->prevpool;
next->prevpool = prev;
prev->nextpool = next;
/*
* Frontlink to free pools
* This ensures that previously freed pools will be allocated
* later (being not referenced, they are perhaps paged out).
*/
pool->nextpool = freepools;
freepools = pool;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
UNLOCK();
return;
}
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/* We did not allocate this address. */
INCTHEIRS;
PyMem_FREE(p);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
}
/* realloc */
void *
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
_PyMalloc_Realloc(void *p, size_t nbytes)
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
{
block *bp;
poolp pool;
uint size;
if (p == NULL)
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
return _PyMalloc_Malloc(nbytes);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/* realloc(p, 0) on big blocks is redirected. */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
pool = POOL_ADDR(p);
if (ADDRESS_IN_RANGE(p, pool->arenaindex)) {
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
/* We're in charge of this block */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
INCMINE;
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
size = (pool->szidx + 1) << ALIGNMENT_SHIFT; /* block size */
if (size >= nbytes) {
/* Don't bother if a smaller size was requested
except for realloc(p, 0) == free(p), ret NULL */
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
/* XXX but Python guarantees that *its* flavor of
resize(p, 0) will not do a free or return NULL */
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
if (nbytes == 0) {
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
_PyMalloc_Free(p);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
bp = NULL;
}
else
bp = (block *)p;
}
else {
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
bp = (block *)_PyMalloc_Malloc(nbytes);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
if (bp != NULL) {
memcpy(bp, p, size);
Drop the PyCore_* memory API.
2002-03-18 17:06:21 -04:00
_PyMalloc_Free(p);
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
}
}
}
Lots of changes: + 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>.
2002-03-30 02:09:22 -04:00
else {
/* We haven't allocated this block */
INCTHEIRS;
if (nbytes <= SMALL_REQUEST_THRESHOLD && nbytes) {
/* small request */
size = nbytes;
bp = (block *)_PyMalloc_Malloc(nbytes);
if (bp != NULL) {
memcpy(bp, p, size);
_PyMalloc_Free(p);
}
}
else
bp = (block *)PyMem_REALLOC(p, nbytes);
}
Add Vladimir Marangozov's object allocator. It is disabled by default. This closes SF patch #401229.
2001-02-27 00:45:05 -04:00
return (void *)bp;
}
Build obmalloc.c directly instead of #include'ing from object.c. 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.
2002-03-22 20:20:15 -04:00
#else /* ! WITH_PYMALLOC */
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
/*==========================================================================*/
/* pymalloc not enabled: Redirect the entry points to the PyMem family. */
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
Just whitespace fiddling.
2002-03-22 20:28:57 -04:00
void *
_PyMalloc_Malloc(size_t n)
Build obmalloc.c directly instead of #include'ing from object.c. 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.
2002-03-22 20:20:15 -04:00
{
return PyMem_MALLOC(n);
}
Just whitespace fiddling.
2002-03-22 20:28:57 -04:00
void *
_PyMalloc_Realloc(void *p, size_t n)
Build obmalloc.c directly instead of #include'ing from object.c. 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.
2002-03-22 20:20:15 -04:00
{
return PyMem_REALLOC(p, n);
}
void
_PyMalloc_Free(void *p)
{
PyMem_FREE(p);
}
#endif /* WITH_PYMALLOC */
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
/*==========================================================================*/
/* Regardless of whether pymalloc is enabled, export entry points for
* the object-oriented pymalloc functions.
*/
Just whitespace fiddling.
2002-03-22 20:28:57 -04:00
PyObject *
_PyMalloc_New(PyTypeObject *tp)
Build obmalloc.c directly instead of #include'ing from object.c. 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.
2002-03-22 20:20:15 -04:00
{
PyObject *op;
op = (PyObject *) _PyMalloc_MALLOC(_PyObject_SIZE(tp));
if (op == NULL)
return PyErr_NoMemory();
return PyObject_INIT(op, tp);
}
PyVarObject *
_PyMalloc_NewVar(PyTypeObject *tp, int nitems)
{
PyVarObject *op;
const size_t size = _PyObject_VAR_SIZE(tp, nitems);
op = (PyVarObject *) _PyMalloc_MALLOC(size);
if (op == NULL)
return (PyVarObject *)PyErr_NoMemory();
return PyObject_INIT_VAR(op, tp, nitems);
}
void
_PyMalloc_Del(PyObject *op)
{
_PyMalloc_FREE(op);
}
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
#ifdef PYMALLOC_DEBUG
/*==========================================================================*/
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
/* A x-platform debugging allocator. This doesn't manage memory directly,
* it wraps a real allocator, adding extra debugging info to the memory blocks.
*/
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
#define PYMALLOC_CLEANBYTE 0xCB /* uninitialized memory */
#define PYMALLOC_DEADBYTE 0xDB /* free()ed memory */
#define PYMALLOC_FORBIDDENBYTE 0xFB /* unusable memory */
static ulong serialno = 0; /* incremented on each debug {m,re}alloc */
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
/* serialno is always incremented via calling this routine. The point is
to supply a single place to set a breakpoint.
*/
static void
Add missing "void" to function.
2002-03-28 17:05:38 -04:00
bumpserialno(void)
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
{
++serialno;
}
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
/* Read 4 bytes at p as a big-endian ulong. */
static ulong
read4(const void *p)
{
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
const uchar *q = (const uchar *)p;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
return ((ulong)q[0] << 24) |
((ulong)q[1] << 16) |
((ulong)q[2] << 8) |
(ulong)q[3];
}
/* Write the 4 least-significant bytes of n as a big-endian unsigned int,
MSB at address p, LSB at p+3. */
static void
write4(void *p, ulong n)
{
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
uchar *q = (uchar *)p;
q[0] = (uchar)((n >> 24) & 0xff);
q[1] = (uchar)((n >> 16) & 0xff);
q[2] = (uchar)((n >> 8) & 0xff);
q[3] = (uchar)( n & 0xff);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
/* The debug malloc asks for 16 extra bytes and fills them with useful stuff,
here calling the underlying malloc's result p:
p[0:4]
Number of bytes originally asked for. 4-byte unsigned integer,
big-endian (easier to read in a memory dump).
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
p[4:8]
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
Copies of PYMALLOC_FORBIDDENBYTE. Used to catch under- writes
and reads.
p[8:8+n]
The requested memory, filled with copies of PYMALLOC_CLEANBYTE.
Used to catch reference to uninitialized memory.
&p[8] is returned. Note that this is 8-byte aligned if PyMalloc
handled the request itself.
p[8+n:8+n+4]
Copies of PYMALLOC_FORBIDDENBYTE. Used to catch over- writes
and reads.
p[8+n+4:8+n+8]
A serial number, incremented by 1 on each call to _PyMalloc_DebugMalloc
and _PyMalloc_DebugRealloc.
4-byte unsigned integer, big-endian.
If "bad memory" is detected later, the serial number gives an
excellent way to set a breakpoint on the next run, to capture the
instant at which this block was passed out.
*/
void *
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
_PyMalloc_DebugMalloc(size_t nbytes)
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
{
uchar *p; /* base address of malloc'ed block */
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
uchar *tail; /* p + 8 + nbytes == pointer to tail pad bytes */
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
size_t total; /* nbytes + 16 */
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
bumpserialno();
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
total = nbytes + 16;
if (total < nbytes || (total >> 31) > 1) {
/* overflow, or we can't represent it in 4 bytes */
/* Obscure: can't do (total >> 32) != 0 instead, because
C doesn't define what happens for a right-shift of 32
when size_t is a 32-bit type. At least C guarantees
size_t is an unsigned type. */
return NULL;
}
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
p = _PyMalloc_Malloc(total);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
if (p == NULL)
return NULL;
write4(p, nbytes);
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
p[4] = p[5] = p[6] = p[7] = PYMALLOC_FORBIDDENBYTE;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
if (nbytes > 0)
memset(p+8, PYMALLOC_CLEANBYTE, nbytes);
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
tail = p + 8 + nbytes;
tail[0] = tail[1] = tail[2] = tail[3] = PYMALLOC_FORBIDDENBYTE;
write4(tail + 4, serialno);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
return p+8;
}
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
/* The debug free first checks the 8 bytes on each end for sanity (in
particular, that the PYMALLOC_FORBIDDENBYTEs are still intact).
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
Then fills the original bytes with PYMALLOC_DEADBYTE.
Then calls the underlying free.
*/
void
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
_PyMalloc_DebugFree(void *p)
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
{
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
uchar *q = (uchar *)p;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
size_t nbytes;
if (p == NULL)
return;
_PyMalloc_DebugCheckAddress(p);
nbytes = read4(q-8);
if (nbytes > 0)
memset(q, PYMALLOC_DEADBYTE, nbytes);
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
_PyMalloc_Free(q-8);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
void *
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
_PyMalloc_DebugRealloc(void *p, size_t nbytes)
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
{
uchar *q = (uchar *)p;
size_t original_nbytes;
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
void *fresh; /* new memory block, if needed */
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
if (p == NULL)
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
return _PyMalloc_DebugMalloc(nbytes);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
_PyMalloc_DebugCheckAddress(p);
original_nbytes = read4(q-8);
if (nbytes == original_nbytes) {
/* note that this case is likely to be common due to the
way Python appends to lists */
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
bumpserialno();
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
write4(q + nbytes + 4, serialno);
return p;
}
if (nbytes < original_nbytes) {
/* shrinking -- leave the guts alone, except to
fill the excess with DEADBYTE */
const size_t excess = original_nbytes - nbytes;
_PyMalloc_DebugRealloc(): simplify decl of "fresh". 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.
2002-03-23 20:34:21 -04:00
bumpserialno();
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
write4(q-8, nbytes);
/* kill the excess bytes plus the trailing 8 pad bytes */
q += nbytes;
q[0] = q[1] = q[2] = q[3] = PYMALLOC_FORBIDDENBYTE;
write4(q+4, serialno);
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
memset(q+8, PYMALLOC_DEADBYTE, excess);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
return p;
}
/* More memory is needed: get it, copy over the first original_nbytes
of the original data, and free the original memory. */
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
fresh = _PyMalloc_DebugMalloc(nbytes);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
if (fresh != NULL && original_nbytes > 0)
memcpy(fresh, p, original_nbytes);
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
_PyMalloc_DebugFree(p);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
return fresh;
}
void
_PyMalloc_DebugCheckAddress(const void *p)
{
const uchar *q = (const uchar *)p;
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
char *msg;
int i;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
if (p == NULL) {
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
msg = "didn't expect a NULL pointer";
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
goto error;
}
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
for (i = 4; i >= 1; --i) {
if (*(q-i) != PYMALLOC_FORBIDDENBYTE) {
msg = "bad leading pad byte";
goto error;
}
}
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
{
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
const ulong nbytes = read4(q-8);
const uchar *tail = q + nbytes;
for (i = 0; i < 4; ++i) {
if (tail[i] != PYMALLOC_FORBIDDENBYTE) {
msg = "bad trailing pad byte";
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
goto error;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
}
}
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
return;
error:
_PyMalloc_DebugDumpAddress(p);
Py_FatalError(msg);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
void
_PyMalloc_DebugDumpAddress(const void *p)
{
const uchar *q = (const uchar *)p;
const uchar *tail;
ulong nbytes, serial;
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
int i;
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
fprintf(stderr, "Debug memory block at address p=%p:\n", p);
if (p == NULL)
return;
nbytes = read4(q-8);
fprintf(stderr, " %lu bytes originally allocated\n", nbytes);
/* In case this is nuts, check the pad bytes before trying to read up
the serial number (the address deref could blow up). */
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
fputs(" the 4 pad bytes at p-4 are ", stderr);
if (*(q-4) == PYMALLOC_FORBIDDENBYTE &&
*(q-3) == PYMALLOC_FORBIDDENBYTE &&
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
*(q-2) == PYMALLOC_FORBIDDENBYTE &&
*(q-1) == PYMALLOC_FORBIDDENBYTE) {
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
fputs("PYMALLOC_FORBIDDENBYTE, as expected\n", stderr);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
else {
fprintf(stderr, "not all PYMALLOC_FORBIDDENBYTE (0x%02x):\n",
PYMALLOC_FORBIDDENBYTE);
PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhere 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.
2002-03-28 03:32:11 -04:00
for (i = 4; i >= 1; --i) {
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
const uchar byte = *(q-i);
fprintf(stderr, " at p-%d: 0x%02x", i, byte);
if (byte != PYMALLOC_FORBIDDENBYTE)
fputs(" *** OUCH", stderr);
fputc('\n', stderr);
}
}
tail = q + nbytes;
fprintf(stderr, " the 4 pad bytes at tail=%p are ", tail);
if (tail[0] == PYMALLOC_FORBIDDENBYTE &&
tail[1] == PYMALLOC_FORBIDDENBYTE &&
tail[2] == PYMALLOC_FORBIDDENBYTE &&
tail[3] == PYMALLOC_FORBIDDENBYTE) {
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
fputs("PYMALLOC_FORBIDDENBYTE, as expected\n", stderr);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
else {
fprintf(stderr, "not all PYMALLOC_FORBIDDENBYTE (0x%02x):\n",
PYMALLOC_FORBIDDENBYTE);
for (i = 0; i < 4; ++i) {
const uchar byte = tail[i];
fprintf(stderr, " at tail+%d: 0x%02x",
i, byte);
if (byte != PYMALLOC_FORBIDDENBYTE)
fputs(" *** OUCH", stderr);
fputc('\n', stderr);
}
}
serial = read4(tail+4);
fprintf(stderr, " the block was made by call #%lu to "
"debug malloc/realloc\n", serial);
if (nbytes > 0) {
int i = 0;
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
fputs(" data at p:", stderr);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
/* print up to 8 bytes at the start */
while (q < tail && i < 8) {
fprintf(stderr, " %02x", *q);
++i;
++q;
}
/* and up to 8 at the end */
if (q < tail) {
if (tail - q > 8) {
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
fputs(" ...", stderr);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
q = tail - 8;
}
while (q < tail) {
fprintf(stderr, " %02x", *q);
++q;
}
}
Minor code cleanup -- no semantic changes.
2002-03-23 18:28:18 -04:00
fputc('\n', stderr);
Give Python a debug-mode pymalloc, much as sketched on Python-Dev. 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.
2002-03-23 06:03:50 -04:00
}
}
#endif /* PYMALLOC_DEBUG */