summaryrefslogtreecommitdiffstats
path: root/Include/objimpl.h
Commit message (Collapse)AuthorAgeFilesLines
* Issue #18112: PEP 442 implementation (safe object finalization).Antoine Pitrou2013-07-301-5/+29
|
* Issue #3329: Implement the PEP 445Victor Stinner2013-07-071-34/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add new enum: * PyMemAllocatorDomain Add new structures: * PyMemAllocator * PyObjectArenaAllocator Add new functions: * PyMem_RawMalloc(), PyMem_RawRealloc(), PyMem_RawFree() * PyMem_GetAllocator(), PyMem_SetAllocator() * PyObject_GetArenaAllocator(), PyObject_SetArenaAllocator() * PyMem_SetupDebugHooks() Changes: * PyMem_Malloc()/PyObject_Realloc() now always call malloc()/realloc(), instead of calling PyObject_Malloc()/PyObject_Realloc() in debug mode. * PyObject_Malloc()/PyObject_Realloc() now falls back to PyMem_Malloc()/PyMem_Realloc() for allocations larger than 512 bytes. * Redesign debug checks on memory block allocators as hooks, instead of using C macros
* Revert changeset 6661a8154eb3: Issue #3329: Add new APIs to customize memory ↵Victor Stinner2013-06-151-39/+34
| | | | | | allocators The new API require more discussion.
* Issue #3329: Add new APIs to customize memory allocatorsVictor Stinner2013-06-141-34/+39
| | | | | | | | | | | | | | | | | | | | * Add a new PyMemAllocators structure * New functions: - PyMem_RawMalloc(), PyMem_RawRealloc(), PyMem_RawFree(): GIL-free memory allocator functions - PyMem_GetRawAllocators(), PyMem_SetRawAllocators() - PyMem_GetAllocators(), PyMem_SetAllocators() - PyMem_SetupDebugHooks() - _PyObject_GetArenaAllocators(), _PyObject_SetArenaAllocators() * Add unit test for PyMem_Malloc(0) and PyObject_Malloc(0) * Add unit test for new get/set allocators functions * PyObject_Malloc() now falls back on PyMem_Malloc() instead of malloc() if size is bigger than SMALL_REQUEST_THRESHOLD, and PyObject_Realloc() falls back on PyMem_Realloc() instead of realloc() * PyMem_Malloc() and PyMem_Realloc() now always call malloc() and realloc(), instead of calling PyObject_Malloc() and PyObject_Realloc() in debug mode
* Issue #17937: Try harder to collect cyclic garbage at shutdown.Antoine Pitrou2013-05-181-0/+4
|
* Using 'long double' to force this structure to be worst case aligned is noGregory P. Smith2012-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | longer required as of Python 2.5+ when the gc_refs changed from an int (4 bytes) to a Py_ssize_t (8 bytes) as the minimum size is 16 bytes. The use of a 'long double' triggered a warning by Clang trunk's Undefined-Behavior Sanitizer as on many platforms a long double requires 16-byte alignment but the Python memory allocator only guarantees 8 byte alignment. So our code would allocate and use these structures with technically improper alignment. Though it didn't matter since the 'dummy' field is never used. This silences that warning. Spelunking into code history, the double was added in 2001 to force better alignment on some platforms and changed to a long double in 2002 to appease Tru64. That issue should no loner be present since the upgrade from int to Py_ssize_t where the minimum structure size increased to 16 (unless anyone knows of a platform where ssize_t is 4 bytes?) or 24 bytes depending on if the build uses 4 or 8 byte pointers. We can probably get rid of the double and this union hack all together today. That is a slightly more invasive change that can be left for later. A more correct non-hacky alternative if any alignment issues are still found would be to use a compiler specific alignment declaration on the structure and determine which value to use at configure time.
* Issue #13390: New function :func:`sys.getallocatedblocks()` returns the ↵Antoine Pitrou2012-12-091-0/+2
| | | | | | number of memory blocks currently allocated. Also, the ``-R`` option to regrtest uses this function to guard against memory allocation leaks.
* Issue #15144: Fix possible integer overflow when handling pointers as ↵Antoine Pitrou2012-09-201-6/+3
| | | | | | integer values, by using Py_uintptr_t instead of size_t. Patch by Serhiy Storchaka.
* Issue #14785: Add sys._debugmallocstats() to help debug low-level memory ↵David Malcolm2012-06-221-1/+3
| | | | allocation issues
* Issue #10333: Remove ancient GC API, which has been deprecated sinceAntoine Pitrou2011-01-041-12/+0
| | | | Python 2.2.
* Merge branches/pep-0384.Martin v. Löwis2010-12-031-1/+2
|
* Recorded merge of revisions 81029 via svnmerge fromAntoine Pitrou2010-05-091-73/+73
| | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r81029 | antoine.pitrou | 2010-05-09 16:46:46 +0200 (dim., 09 mai 2010) | 3 lines Untabify C files. Will watch buildbots. ........
* http://bugs.python.org/issue6836Kristján Valur Jónsson2009-09-281-0/+7
| | | | Merging revisions 75103,75104 from trunk to py3k
* Merged revisions 70546 via svnmerge fromAntoine Pitrou2009-03-231-0/+11
| | | | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r70546 | antoine.pitrou | 2009-03-23 19:41:45 +0100 (lun., 23 mars 2009) | 9 lines Issue #4688: Add a heuristic so that tuples and dicts containing only untrackable objects are not tracked by the garbage collector. This can reduce the size of collections and therefore the garbage collection overhead on long-running programs, depending on their particular use of datatypes. (trivia: this makes the "binary_trees" benchmark from the Computer Language Shootout 40% faster) ........
* #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and Py_REFCNT.Christian Heimes2007-12-191-5/+5
|
* Remove _PyObject_DelNeal Norwitz2007-08-191-3/+0
|
* Merged revisions 56467-56482 via svnmerge fromMartin v. Löwis2007-07-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/branches/p3yk ................ r56477 | martin.v.loewis | 2007-07-21 09:04:38 +0200 (Sa, 21 Jul 2007) | 11 lines Merged revisions 56466-56476 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r56476 | martin.v.loewis | 2007-07-21 08:55:02 +0200 (Sa, 21 Jul 2007) | 4 lines PEP 3123: Provide forward compatibility with Python 3.0, while keeping backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT. ........ ................ r56478 | martin.v.loewis | 2007-07-21 09:47:23 +0200 (Sa, 21 Jul 2007) | 2 lines PEP 3123: Use proper C inheritance for PyObject. ................ r56479 | martin.v.loewis | 2007-07-21 10:06:55 +0200 (Sa, 21 Jul 2007) | 3 lines Add longintrepr.h to Python.h, so that the compiler can see that PyFalse is really some kind of PyObject*. ................ r56480 | martin.v.loewis | 2007-07-21 10:47:18 +0200 (Sa, 21 Jul 2007) | 2 lines Qualify SHIFT, MASK, BASE. ................ r56482 | martin.v.loewis | 2007-07-21 19:10:57 +0200 (Sa, 21 Jul 2007) | 2 lines Correctly refer to _ob_next. ................
* Get rid of most of the flags (in tp_flags) that keep track of variousGuido van Rossum2006-07-271-3/+1
| | | | | | variations of the type struct and its attachments. In Py3k, all type structs have to have all fields -- no binary backwards compatibility. Had to change the complex object to a new-style number!
* Merge p3yk branch with the trunk up to revision 45595. This breaks a fairThomas Wouters2006-04-211-13/+9
| | | | | | | | | | | | | | | | | | | | number of tests, all because of the codecs/_multibytecodecs issue described here (it's not a Py3K issue, just something Py3K discovers): http://mail.python.org/pipermail/python-dev/2006-April/064051.html Hye-Shik Chang promised to look for a fix, so no need to fix it here. The tests that are expected to break are: test_codecencodings_cn test_codecencodings_hk test_codecencodings_jp test_codecencodings_kr test_codecencodings_tw test_codecs test_multibytecodec This merge fixes an actual test failure (test_weakref) in this branch, though, so I believe merging is the right thing to do anyway.
* Make PyGC_Collect() use Py_ssize_t.Neal Norwitz2006-03-041-1/+1
|
* Change GC refcount to Py_ssize_t.Martin v. Löwis2006-03-011-1/+1
|
* Change _PyObject_GC_Resize to expect Py_ssize_t.Martin v. Löwis2006-02-161-1/+1
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-3/+3
|
* Fix PyGC_Collect() to be exported from the built DLL on Windows. (Fix givenBarry Warsaw2006-01-261-1/+1
| | | | by Matt Messier).
* [ 1243081 ] repair typosGeorg Brandl2005-07-221-1/+1
|
* Formalize that the Py_VISIT macro requires that the tp_traverseTim Peters2004-07-151-1/+5
| | | | implementation it's used in must give its arguments specific names.
* Documented the new Py_VISIT macro to simplify implementation ofJim Fulton2004-07-141-0/+10
| | | | tp_traverse handlers. (Tim made me do it. ;)
* - New C API PyGC_Collect(), same as calling gc.collect().Guido van Rossum2003-04-171-0/+3
| | | | | - Call this in Py_Finalize(). - Expand the Misc/NEWS text on PY_LONG_LONG.
* Excise DL_EXPORT from Include.Mark Hammond2002-08-121-20/+20
| | | | Thanks to Skip Montanaro and Kalle Svensson for the patches.
* Removed WITH_CYCLE_GC #ifdef-ery. Holes:Tim Peters2002-07-071-19/+0
| | | | | | + I'm not sure what to do about configure.in. Left it alone. + Ditto pyexpat.c. Fred or Martin will know what to do.
* Finished transitioning to using gc_refs to track gc objects' states.Tim Peters2002-07-021-3/+5
| | | | | | | This was mostly a matter of adding comments and light code rearrangement. Upon untracking, gc_next is still set to NULL. It's a cheap way to provoke memory faults if calling code is insane. It's also used in some way by the trashcan mechanism.
* Reserved another gc_refs value for untracked objects. Every live gcTim Peters2002-07-021-2/+10
| | | | | | | | | | | | object should now have a well-defined gc_refs value, with clear transitions among gc_refs states. As a result, none of the visit_XYZ traversal callbacks need to check IS_TRACKED() anymore, and those tests were removed. (They were already looking for objects with specific gc_refs states, and the gc_refs state of an untracked object can no longer match any other gc_refs state by accident.) Added more asserts. I expect that the gc_next == NULL indicator for an untracked object is now redundant and can also be removed, but I ran out of time for this.
* _PyGC_generation0 is now a pointerNeil Schemenauer2002-05-041-4/+4
|
* Moving pymalloc along.Tim Peters2002-04-281-75/+89
| | | | | | | | | | As threatened, PyMem_{Free, FREE} also invoke the object deallocator now when pymalloc is enabled (well, it does when pymalloc isn't enabled too, but in that case "the object deallocator" is plain free()). This is maximally backward-compatible, but it leaves a bitter aftertaste. Also massive reworking of comments.
* _PyObject_DebugDumpStats: renamed to _PyObject_DebugMallocStats.Tim Peters2002-04-131-1/+1
| | | | | | Added code to call this when PYMALLOC_DEBUG is enabled, and envar PYTHONMALLOCSTATS is set, whenever a new arena is obtained and once late in the Python shutdown process.
* First cut at repairing out-of-date comments; make alignment of macro defsTim Peters2002-04-121-15/+24
| | | | all the same within the #ifdef WITH_PYMALLOC block.
* Remove PyMalloc_* symbols. PyObject_Malloc now uses pymalloc ifNeil Schemenauer2002-04-121-38/+44
| | | | | | | | | | it's enabled. Allow PyObject_Del, PyObject_Free, and PyObject_GC_Del to be used as function designators. Provide source compatibility macros. Make PyObject_GC_Track and PyObject_GC_UnTrack functions instead of trivial macros wrapping functions.
* Add _Py_AS_GC macro. It will be used by the trashcan code on object.c.Neil Schemenauer2002-03-281-2/+4
|
* Make PyObject_{NEW,New,Del,DEL} always use the standard malloc (PyMem_*)Neil Schemenauer2002-03-221-8/+23
| | | | | | and not pymalloc. Add the functions PyMalloc_New, PyMalloc_NewVar, and PyMalloc_Del that will use pymalloc if it's enabled. If pymalloc is not enabled then they use the standard malloc (PyMem_*).
* Drop the PyCore_* memory API.Neil Schemenauer2002-03-181-45/+8
|
* Simpilify PyCore_* macros by assuming the function prototypes forNeil Schemenauer2002-03-181-29/+9
| | | | malloc() and free() don't change.
* PyGC_Head: Use "long double" instead of "double" as the worst-caseTim Peters2002-02-281-1/+1
| | | | | | | alignment gimmick. David Abrahams notes that the standard "long double" actually requires stricter alignment than "double" on some Tru64 box. On my box and yours <wink>, it's the same, so no harm done on most boxes.
* SF bug [#467145] Python 2.2a4 build problem on HPUX 11.0.Tim Peters2001-10-111-12/+15
| | | | | | | | | | | | | | The platform requires 8-byte alignment for doubles, but the GC header was 12 bytes and that threw off the natural alignment of the double members of a subtype of complex. The fix puts the GC header into a union with a double as the other member, to force no-looser-than double alignment of GC headers. On boxes that require 8-byte alignment for doubles, this may add pad bytes to the GC header accordingly; ditto for platforms that *prefer* 8-byte alignment for doubles. On platforms that don't care, it shouldn't change the memory layout (because the size of the old GC header is certainly greater than the size of a double on all platforms, so unioning with a double shouldn't change size or alignment on such boxes).
* Guido suggests, and I agree, to insist that SIZEOF_VOID_P be a power of 2.Tim Peters2001-10-071-28/+24
| | | | | | This simplifies the rounding in _PyObject_VAR_SIZE, allows to restore the pre-rounding calling sequence, and allows some nice little simplifications in its callers. I'm still making it return a size_t, though.
* _PyObject_VAR_SIZE: always round up to a multiple-of-pointer-size value.Tim Peters2001-10-061-11/+35
| | | | | | | | | | | | | | | | | As Guido suggested, this makes the new subclassing code substantially simpler. But the mechanics of doing it w/ C macro semantics are a mess, and _PyObject_VAR_SIZE has a new calling sequence now. Question: The PyObject_NEW_VAR macro appears to be part of the public API. Regardless of what it expands to, the notion that it has to round up the memory it allocates is new, and extensions containing the old PyObject_NEW_VAR macro expansion (which was embedded in the PyObject_NEW_VAR expansion) won't do this rounding. But the rounding isn't actually *needed* except for new-style instances with dict pointers after a variable-length blob of embedded data. So my guess is that we do not need to bump the API version for this (as the rounding isn't needed for anything an extension can do unless it's recompiled anyway). What's your guess?
* Repaired the debug Windows deaths in test_descr, by allocating enoughTim Peters2001-10-061-1/+2
| | | | | | | | | | | | | | pad memory to properly align the __dict__ pointer in all cases. gcmodule.c/objimpl.h, _PyObject_GC_Malloc: + Added a "padding" argument so that this flavor of malloc can allocate enough bytes for alignment padding (it can't know this is needed, but its callers do). typeobject.c, PyType_GenericAlloc: + Allocated enough bytes to align the __dict__ pointer. + Sped and simplified the round-up-to-PTRSIZE logic. + Added blank lines so I could parse the if/else blocks <0.7 wink>.
* Add Garbage Collection support to new-style classes (not yet to theirGuido van Rossum2001-10-021-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | instances). Also added GC support to various auxiliary types: super, property, descriptors, wrappers, dictproxy. (Only type objects have a tp_clear field; the other types are.) One change was necessary to the GC infrastructure. We have statically allocated type objects that don't have a GC header (and can't easily be given one) and heap-allocated type objects that do have a GC header. Giving these different metatypes would be really ugly: I tried, and I had to modify pickle.py, cPickle.c, copy.py, add a new invent a new name for the new metatype and make it a built-in, change affected tests... In short, a mess. So instead, we add a new type slot tp_is_gc, which is a simple Boolean function that determines whether a particular instance has GC headers or not. This slot is only relevant for types that have the (new) GC flag bit set. If the tp_is_gc slot is NULL (by far the most common case), all instances of the type are deemed to have GC headers. This slot is called by the PyObject_IS_GC() macro (which is only used twice, both times in gcmodule.c). I also changed the extern declarations for a bunch of GC-related functions (_PyObject_GC_Del etc.): these always exist but objimpl.h only declared them when WITH_CYCLE_GC was defined, but I needed to be able to reference them without #ifdefs. (When WITH_CYCLE_GC is not defined, they do the same as their non-GC counterparts anyway.)
* Fix the names of _PyObject_GC_TRACK and _PyObject_GC_UNTRACK when the GC isNeil Schemenauer2001-09-031-2/+2
| | | | disabled. Obviously everyone enables the GC. :-)
* Change the GC type flag since the API has changed. Allow types usingNeil Schemenauer2001-08-291-50/+66
| | | | | | | the old flag to still compile. Remove the PyType_BASICSIZE and PyType_SET_BASICSIZE macros. Add PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del, PyObject_GC_Track, PyObject_GC_UnTrack. Part of SF patch #421893.
* Removed duplicate definnitions of PyObject_AS_GC and PyObject_FROM_GC ↵Jack Jansen2001-08-031-2/+0
| | | | (occurred only if GC was off).
generated by cgit v0.12 at 2024-12-03 22:46:04 (GMT)