summaryrefslogtreecommitdiffstats
path: root/Modules/gcmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* Untabify C files. Will watch buildbots.Antoine Pitrou2010-05-091-881/+881
|
* Issue #4687: Fix accuracy of garbage collection runtimes displayed withAntoine Pitrou2010-05-021-1/+1
| | | | gc.DEBUG_STATS.
* Fix a typo in commentAmaury Forgeot d'Arc2009-12-271-2/+2
|
* Issue #4688: Add a heuristic so that tuples and dicts containing onlyAntoine Pitrou2009-03-231-1/+29
| | | | | | | | | 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)
* fix building the core with --disable-unicodeBenjamin Peterson2009-01-251-0/+2
| | | | | I changed some bytearray methods to use strings instead of unicode like bytes_repr Also, bytearray.fromhex() can take strings as well as unicode
* Issue #4074: Change the criteria for doing a full garbage collection (i.e.Antoine Pitrou2009-01-091-1/+65
| | | | | | collecting the oldest generation) so that allocating lots of objects without destroying them does not show quadratic performance. Based on a proposal by Martin von Löwis at http://mail.python.org/pipermail/python-dev/2008-June/080579.html.
* Issue #2467: gc.DEBUG_STATS reports invalid elapsed times.Antoine Pitrou2008-12-171-23/+26
| | | | Patch by Neil Schemenauer, very slightly modified.
* Security patches from Apple: prevent int overflow when allocating memoryNeal Norwitz2008-07-311-1/+6
|
* - Issue #2862: Make int and float freelist management consistent with otherGregory P. Smith2008-07-061-0/+2
| | | | | freelists. Changes their CompactFreeList apis into ClearFreeList apis and calls them via gc.collect().
* This reverts r63675 based on the discussion in this thread:Gregory P. Smith2008-06-091-4/+4
| | | | | | | http://mail.python.org/pipermail/python-dev/2008-June/079988.html Python 2.6 should stick with PyString_* in its codebase. The PyBytes_* names in the spirit of 3.0 are available via a #define only. See the email thread.
* Renamed PyString to PyBytesChristian Heimes2008-05-261-4/+4
|
* Implemented Martin's suggestion to clear the free lists during the garbage ↵Christian Heimes2008-02-141-0/+22
| | | | collection of the highest generation.
* Modified PyImport_Import and PyImport_ImportModule to always use absolute ↵Christian Heimes2008-01-031-1/+1
| | | | | | imports by calling __import__ with an explicit level of 0 Added a new API function PyImport_ImportModuleNoBlock. It solves the problem with dead locks when mixing threads and imports
* #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and ↵Christian Heimes2007-12-191-11/+11
| | | | Py_REFCNT. Macros for b/w compatibility are available.
* PEP 3123: Provide forward compatibility with Python 3.0, while keepingMartin v. Löwis2007-07-211-11/+11
| | | | | backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT.
* List gc.get_count() in the module docstring.Barry Warsaw2006-10-091-0/+1
|
* Replace PyObject_CallFunction calls with only object argsGeorg Brandl2006-05-251-1/+1
| | | | with PyObject_CallFunctionObjArgs, which is 30% faster.
* Patch from Aldo Cortesi (OpenBSD buildbot owner).Neal Norwitz2006-04-261-7/+14
| | | | | | | | | | After the patch (45590) to add extra debug stats to the gc module, Python was crashing on OpenBSD due to: Fatal Python error: Interpreter not initialized (version mismatch?) This seems to occur due to calling collect() when initialized (in pythonrun.c) is set to 0. Now, the import will occur in the init function which shouldn't suffer this problem.
* This is a long-ago patch I submitted to SF (1100924) to time the gc passes.Skip Montanaro2006-04-211-0/+29
| | | | | Barry approved it awhile ago. Been sitting in my sandbox for awhile as well.
* Some more changes to make code compile under a C++ compiler.Anthony Baxter2006-04-111-2/+3
|
* SF Patch #1463867: Improved generator finalization to allow generatorsPhillip J. Eby2006-04-101-1/+5
| | | | | | | | that are suspended outside of any try/except/finally blocks to be garbage collected even if they are part of a cycle. Generators that suspend inside of an active try/except or try/finally block (including those created by a ``with`` statement) are still not GC-able if they are part of a cycle, however.
* Handle ssize_tNeal Norwitz2006-04-061-2/+2
|
* In format strings slinging Py_ssize_t, unconditionallyTim Peters2006-03-281-22/+9
| | | | | interpolate PY_FORMAT_SIZE_T instead of #if'ing on MS_WIN64.
* Fix some missing checks after PyTuple_New, PyList_New, PyDict_NewGeorg Brandl2006-03-171-0/+2
|
* SF patch #1443865; gc.get_count() added and optional argument 'generation'Barry Warsaw2006-03-071-5/+34
| | | | | | added to gc.collect(). Updated docs, unit test, and NEWS entry. (Also, fixed a typo in NEWS.)
* Fix warnings on x86 (32-bit) and support Win64.Neal Norwitz2006-03-061-2/+15
|
* Make PyGC_Collect() use Py_ssize_t.Neal Norwitz2006-03-041-11/+11
|
* 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-1/+1
|
* Check return result from Py_InitModule*(). This API can fail.Neal Norwitz2006-01-191-0/+2
| | | | Probably should be backported.
* PEP 342 implementation. Per Guido's comments, the generator throw()Phillip J. Eby2005-08-021-3/+1
| | | | | method still needs to support string exceptions, and allow None for the third argument. Documentation updates are needed, too.
* Add missing INCREF.Neil Schemenauer2005-06-181-0/+1
| | | | Backport candidate.
* gc_list_move(): Make this truly equivalent to remove+append. WhileTim Peters2004-11-011-3/+5
| | | | | | nothing in gc currently cares, the original coding could screw up if, e.g., you tried to move a node to the list it's already in, and the node was already the last in its list.
* gc list function cleanup.Tim Peters2004-11-011-15/+31
| | | | | | | | | | | Introduced gc_list_move(), which captures the common gc_list_remove() + gc_list_append() sequence. In fact, no uses of gc_list_append() remained (they were all in a gc_list_move() sequence), so commented that one out. gc_list_merge(): assert that `from` != `to`; that was an implicit precondition, now verified in a debug build. Others: added comments about their purpose.
* handle_weakrefs(): Simplification -- there's no need to make a secondTim Peters2004-10-311-58/+28
| | | | pass over the unreachable weakrefs-with-callbacks to unreachable objects.
* SF 1055820: weakref callback vs gc vs threadsTim Peters2004-10-301-106/+183
| | | | | | | | In cyclic gc, clear weakrefs to unreachable objects before allowing any Python code (weakref callbacks or __del__ methods) to run. This is a critical bugfix, affecting all versions of Python since weakrefs were introduced. I'll backport to 2.3.
* Convert return value to boolean.Raymond Hettinger2004-01-041-1/+1
|
* Silence GCC warning when asserts are turned off.Guido van Rossum2003-11-241-2/+1
|
* SF bug 839548: Bug in type's GC handling causes segfaults.Tim Peters2003-11-201-13/+129
| | | | | | | | Also SF patch 843455. This is a critical bugfix. I'll backport to 2.3 maint, but not beyond that. The bugs this fixes have been there since weakrefs were introduced.
* update_refs(): assert that incoming refcounts aren't 0. The commentTim Peters2003-11-141-0/+19
| | | | | | | | for this function has always claimed that was true, but it wasn't verified before. For the latest batch of "double deallocation" bugs (stemming from weakref callbacks invoked by way of subtype_dealloc), this assert would have triggered (instead of waiting for _Py_ForgetReference to die with a segfault later).
* Bug #794140: cygwin builds do not embedJason Tishler2003-09-041-1/+1
| | | | | | The embed2.diff patch solves the user's problem by exporting the missing symbols from the Python core so Python can be embedded in another Cygwin application (well, at lest vim).
* - New C API PyGC_Collect(), same as calling gc.collect().Guido van Rossum2003-04-171-1/+19
| | | | | - Call this in Py_Finalize(). - Expand the Misc/NEWS text on PY_LONG_LONG.
* s/referrents/referents/g. Gotta love that referrers remains rife with rs.Tim Peters2003-04-081-8/+8
|
* Finished implementing gc.get_referrents(): dealt with error and endTim Peters2003-04-081-6/+15
| | | | cases, wrote docs, added a test.
* Comment repair; no semantic changes.Tim Peters2003-04-071-4/+5
|
* Reworked has_finalizer() to use the new _PyObject_Lookup() insteadTim Peters2003-04-071-73/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of PyObject_HasAttr(); the former promises never to execute arbitrary Python code. Undid many of the changes recently made to worm around the worst consequences of that PyObject_HasAttr() could execute arbitrary Python code. Compatibility is hard to discuss, because the dangerous cases are so perverse, and much of this appears to rely on implementation accidents. To start with, using hasattr() to check for __del__ wasn't only dangerous, in some cases it was wrong: if an instance of an old- style class didn't have "__del__" in its instance dict or in any base class dict, but a getattr hook said __del__ existed, then hasattr() said "yes, this object has a __del__". But instance_dealloc() ignores the possibility of getattr hooks when looking for a __del__, so while object.__del__ succeeds, no __del__ method is called when the object is deleted. gc was therefore incorrect in believing that the object had a finalizer. The new method doesn't suffer that problem (like instance_dealloc(), _PyObject_Lookup() doesn't believe __del__ exists in that case), but does suffer a somewhat opposite-- and even more obscure --oddity: if an instance of an old-style class doesn't have "__del__" in its instance dict, and a base class does have "__del__" in its dict, and the first base class with a "__del__" associates it with a descriptor (an object with a __get__ method), *and* if that descriptor raises an exception when __get__ is called, then (a) the current method believes the instance does have a __del__, but (b) hasattr() does not believe the instance has a __del__. While these disagree, I believe the new method is "more correct": because the descriptor *will* be called when the object is destructed, it can execute arbitrary Python code at the time the object is destructed, and that's really what gc means by "has a finalizer": not specifically a __del__ method, but more generally the possibility of executing arbitrary Python code at object destruction time. Code in a descriptor's __get__() executed at destruction time can be just as problematic as code in a __del__() executed then. So I believe the new method is better on all counts. Bugfix candidate, but it's unclear to me how all this differs in the 2.2 branch (e.g., new-style and old-style classes already took different gc paths in 2.3 before this last round of patches, but don't in the 2.2 branch).
* initgc(): Rewrote to use the PyModule_AddXYZ API; cuts code size.Tim Peters2003-04-061-17/+14
|
* handle_finalizers(): Rewrote to call append_objects() and gc_list_merge()Tim Peters2003-04-061-36/+31
| | | | | | | | | instead of looping. Smaller and clearer. Faster, too, when we're not appending to gc.garbage: gc_list_merge() takes constant time, regardless of the lists' sizes. append_objects(): Moved up to live with the other list manipulation utilities.
* Switched from METH_VARARGS to METH_NOARGS for the 7 module functions thatTim Peters2003-04-061-44/+17
| | | | take no arguments; cuts generated code size.
generated by cgit v0.12 at 2025-03-10 09:00:20 (GMT)