summaryrefslogtreecommitdiffstats
path: root/Modules/gcmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Reworked move_finalizer_reachable() to create two distinct lists:Tim Peters2003-04-061-31/+57
| | | | | | | | | externally unreachable objects with finalizers, and externally unreachable objects without finalizers reachable from such objects. This allows us to call has_finalizer() at most once per object, and so limit the pain of nasty getattr hooks. This fixes the failing "boom 2" example Jeremy posted (a non-printing variant of which is now part of test_gc), via never triggering the nasty part of its __getattr__ method.
* move_finalizers(): Rewrote. It's not necessary for this routineTim Peters2003-04-051-29/+20
| | | | | | | | | | | | | | to special-case classic classes, or to worry about refcounts; has_finalizer() deleted the current object iff the first entry in the unreachable list has changed. I don't believe it was correct to check for ob_refcnt == 1, either: the dealloc routine would get called by Py_DECREF then, but there's nothing to stop the dealloc routine from ressurecting the object, and then gc would remain at the head of the unreachable list despite that its refcount temporarily fell to 0 (and that would lead to an infinite loop in move_finalizers()). I'm still worried about has_finalizer() resurrecting other objects in the unreachable list: what's to stop them from getting collected?
* New comments. Rewrote has_finalizer() as a sequence of ifs instead ofTim Peters2003-04-051-6/+21
| | | | | | squashed-together conditional operators; makes it much easier to step thru in the debugger, and to set a breakpoint on the only dangerous path.
* Fixed new seemingly random segfaults, by moving the initialization ofTim Peters2003-04-051-8/+11
| | | | | | | | | | delstr from initgc() into collect(). initgc() isn't called unless the user explicitly imports gc, so can be used only for initialization of user-visible module features; delstr needs to be initialized for proper internal operation, whether or not gc is explicitly imported. Bugfix candidate? I don't know whether the new bug was backported to 2.2 already.
* Fix Tim's boom example.Jeremy Hylton2003-04-041-20/+54
| | | | | move_finalizers() moves every object from unreachable to collectable or finalizers, unless the object is deallocated first.
* Add get_referrents() helper function.Jeremy Hylton2003-04-031-1/+1
|
* Add get_referrents() helper function.Jeremy Hylton2003-04-031-1/+32
|
* Fix typo.Martin v. Löwis2002-11-091-1/+1
|
* For new-style classes, we can now test for tp_del instead of askingGuido van Rossum2002-08-091-3/+3
| | | | for a __del__ attribute, to see if there's a finalizer.
* Trashcan cleanup: Now that cyclic gc is always there, the trashcanTim Peters2002-07-071-0/+3
| | | | | | | | | | | | | | | | | | | mechanism is no longer evil: it no longer plays dangerous games with the type pointer or refcounts, and objects in extension modules can play along too without needing to edit the core first. Rewrote all the comments to explain this, and (I hope) give clear guidance to extension authors who do want to play along. Documented all the functions. Added more asserts (it may no longer be evil, but it's still dangerous <0.9 wink>). Rearranged the generated code to make it clearer, and to tolerate either the presence or absence of a semicolon after the macros. Rewrote _PyTrash_destroy_chain() to call tp_dealloc directly; it was doing a Py_DECREF again, and that has all sorts of obscure distorting effects in non-release builds (Py_DECREF was already called on the object!). Removed Christian's little "embedded change log" comments -- that's what checkin messages are for, and since it was impossible to correlate the comments with the code that changed, I found them merely distracting.
* Removed WITH_CYCLE_GC #ifdef-ery. Holes:Tim Peters2002-07-071-23/+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.
* gc_list_move defined but not used.Michael W. Hudson2002-07-041-15/+0
|
* visit_decref(): Added another assert.Tim Peters2002-07-021-0/+1
|
* Finished transitioning to using gc_refs to track gc objects' states.Tim Peters2002-07-021-39/+66
| | | | | | | 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-6/+16
| | | | | | | | | | | | 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.
generated by cgit v0.12 at 2024-12-04 01:01:59 (GMT)