summaryrefslogtreecommitdiffstats
path: root/Modules/gcmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what'sTim Peters2002-07-011-96/+163
| | | | | | | | | | | | | | | | | | | in gc_refs, even at the cost of putting back a test+branch in visit_decref. The good news: since gc_refs became utterly tame then, it became clear that another special value could be useful. The move_roots() and move_root_reachable() passes have now been replaced by a single move_unreachable() pass. Besides saving a pass over the generation, this has a better effect: most of the time everything turns out to be reachable, so we were breaking the generation list apart and moving it into into the reachable list, one element at a time. Now the reachable stuff stays in the generation list, and the unreachable stuff is moved instead. This isn't quite as good as it sounds, since sometimes we guess wrongly that a thing is unreachable, and have to move it back again. Still, overall, it yields a significant (but not dramatic) boost in collection speed.
* visit_decref(): Two optimizations.Tim Peters2002-06-301-5/+3
| | | | | | | | | | | | | | | | | | | | | | 1. You're not supposed to call this with a NULL argument, although the docs could be clearer about that. The other visit_XYZ() functions don't bother to check. This doesn't either now, although it does assert non-NULL-ness now. 2. It doesn't matter whether the object is currently tracked, so don't bother checking that either (if it isn't currently tracked, it may have some nonsense value in gc_refs, but it doesn't hurt to decrement gibberish, and it's cheaper to do so than to make everyone test for trackedness). It would be nice to get rid of the other tests on IS_TRACKED. Perhaps trackedness should not be a matter of not being in any gc list, but should be a matter of being in a new "untracked" gc list. This list simply wouldn't be involved in the collection mechanism. A newly created object would be put in the untracked list. Tracking would simply unlink it and move it into the gen0 list. Untracking would do the reverse. No test+branch needed then. visit_move() may be vulnerable then, though, and I don't know how this would work with the trashcan.
* SF bug #574132: Major GC related performance regressionTim Peters2002-06-301-13/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "The regression" is actually due to that 2.2.1 had a bug that prevented the regression (which isn't a regression at all) from showing up. "The regression" is actually a glitch in cyclic gc that's been there forever. As the generation being collected is analyzed, objects that can't be collected (because, e.g., we find they're externally referenced, or are in an unreachable cycle but have a __del__ method) are moved out of the list of candidates. A tricksy scheme uses negative values of gc_refs to mark such objects as being moved. However, the exact negative value set at the start may become "more negative" over time for objects not in the generation being collected, and the scheme was checking for an exact match on the negative value originally assigned. As a result, objects in generations older than the one being collected could get scanned too, and yanked back into a younger generation. Doing so doesn't lead to an error, but doesn't do any good, and can burn an unbounded amount of time doing useless work. A test case is simple (thanks to Kevin Jacobs for finding it!): x = [] for i in xrange(200000): x.append((1,)) Without the patch, this ends up scanning all of x on every gen0 collection, scans all of x twice on every gen1 collection, and x gets yanked back into gen1 on every gen0 collection. With the patch, once x gets to gen2, it's never scanned again until another gen2 collection, and stays in gen2. Bugfix candidate, although the code has changed enough that I think I'll need to port it by hand. 2.2.1 also has a different bug that causes bound method objects not to get tracked at all (so the test case doesn't burn absurd amounts of time in 2.2.1, but *should* <wink>).
* Fix small bug. The count of objects in all generations younger then theNeil Schemenauer2002-06-281-1/+1
| | | | collected one should be zeroed.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-32/+22
|
* Remove casts to PyObject * when declaration is for PyObject *Jeremy Hylton2002-06-061-3/+3
|
* Add IS_TRACKED and IS_MOVED macros. This makes the logic a little more clear.Neil Schemenauer2002-05-211-7/+10
|
* Move all data for a single generation into a structure. The set ofNeil Schemenauer2002-05-041-73/+97
| | | | | | | | | | | | generations is now an array. This cleans up some code and makes it easy to change the number of generations. Also, implemented a gc_list_is_empty() function. This makes the logic a little clearer in places. The performance impact of these changes should be negligible. One functional change is that allocation/collection counters are always zeroed at the start of a collection. This should fix SF bug #551915. This change is too big for back-porting but the minimal patch on SF looks good for a bugfix release.
* _PyObject_GC_New: Could call PyObject_INIT with a NULL 1st argument.Tim Peters2002-04-281-2/+6
| | | | | | _PyObject_GC_NewVar: Could call PyObject_INIT_VAR likewise. Bugfix candidate.
* Allow PyObject_Del to be used as a function designator. Provide binaryNeil Schemenauer2002-04-121-14/+39
| | | | | | | | compatibility function. Make PyObject_GC_Track and PyObject_GC_UnTrack functions instead of trivial macros wrapping functions. Provide binary compatibility functions.
* Make _PyObject_GC_UnTrack do nothing if WITH_CYCLE_GC is not defined.Neil Schemenauer2002-03-291-0/+2
|
* This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).Guido van Rossum2002-03-281-1/+3
| | | | | | | | The fix makes it possible to call PyObject_GC_UnTrack() more than once on the same object, and then move the PyObject_GC_UnTrack() call to *before* the trashcan code is invoked. BUGFIX CANDIDATE!
* Use pymalloc for realloc() as well.Neil Schemenauer2002-03-221-2/+2
|
* Use pymalloc if it's enabled.Neil Schemenauer2002-03-221-4/+4
|
* Fix spelling mistakes. Bugfix candidates.Neal Norwitz2002-01-291-1/+1
|
* Check for NULL return value of PyList_New (follow-up to patch #486743).Martin v. Löwis2001-12-021-0/+3
|
* Patch #486743: remove bad INCREF, propagate exception in append_objects.Martin v. Löwis2001-12-021-6/+11
|
* Use identity instead of equality when looking for referrers. Fixes #485781.Martin v. Löwis2001-11-291-3/+4
|
* Rename get_referents to get_referrers. Fixes #483815.Martin v. Löwis2001-11-241-12/+12
|
* has_finalizer(): simplified "if (complicated_bool) 1 else 0" toTim Peters2001-11-011-8/+3
| | | | "complicated_bool".
* Add has_finalizer predictate function. Use it when deciding whichNeil Schemenauer2001-11-011-14/+26
| | | | | | | | | | | objects to save in gc.garbage. This should be the last change needed to fix SF bug 477059: "__del__ on new classes vs. GC". Note that this change slightly changes the behavior of the collector. Before, if a cycle was found that contained instances with __del__ methods then all instance objects in that cycle were saved in gc.garbage. Now, only objects with __del__ methods are saved in gc.garbage.
* SF bug #477059 (my own): __del__ on new classes vs. GC.Guido van Rossum2001-11-011-1/+3
| | | | | | When moving objects with a __del__ attribute to a special list, look for __del__ on new-style classes with the HEAPTYPE flag set as well. (HEAPTYPE means the class was created by a class statement.)
* Make the gc.collect() function respect the collection lock. This fixesNeil Schemenauer2001-10-311-4/+11
| | | | SF bug 476129: "gc.collect sometimes hangs".
* Use double curly braces for the generation0/1/2 initializers, to shutGuido van Rossum2001-10-121-3/+3
| | | | up GCC warnings.
* SF bug [#467145] Python 2.2a4 build problem on HPUX 11.0.Tim Peters2001-10-111-56/+56
| | | | | | | | | | | | | | 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-12/+4
| | | | | | 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-14/+21
| | | | | | | | | | | | | | | | | 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-7/+8
| | | | | | | | | | | | | | 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>.
* _PyObject_GC_Malloc(): split a complicated line in two. As is, there wasTim Peters2001-10-061-2/+3
| | | | | no way to talk the debugger into showing me how many bytes were being allocated.
* Make more things internal to this file. RemoveNeil Schemenauer2001-08-301-93/+148
| | | | | | | | | visit_finalizer_reachable since it's the same as visit_reachable. Rename visit_reachable to visit_move. Objects can now have the GC type flag set, reachable by tp_traverse and not be in a GC linked list. This should make the collector more robust and easier to use by extension module writers. Add memory management functions for container objects (new, del, resize).
* Remove "referents" structure (it's not needed). Check return valueNeil Schemenauer2001-08-101-20/+17
| | | | of PyList_Append.
* Add get_objects function. This is a low level function (likeNeil Schemenauer2001-08-091-0/+38
| | | | | get_referents, and is not yet documented in the library manual). Suggestions for a better name welcome.
* Add get_referents function. Closes SF patch #402925.Neil Schemenauer2001-08-091-0/+50
|
* - update Neil's email addressNeil Schemenauer2000-10-041-6/+2
|
* - do not start collection during processing of an exceptionNeil Schemenauer2000-10-041-1/+5
|
* Fix some long/"l" int/"i" mismatches. Fixes bug #113779.Neil Schemenauer2000-09-221-2/+2
|
* - Add DEBUG_SAVEALL option. When enabled all garbage objects found by theNeil Schemenauer2000-09-221-27/+39
| | | | | | | collector will be saved in gc.garbage. This is useful for debugging a program that creates reference cycles. - Fix else statements in gcmodule.c to conform to Python coding standards.
* compromise value for threshold0: not too high, not too lowJeremy Hylton2000-09-051-1/+1
|
* set the default threshold much higherJeremy Hylton2000-09-011-1/+1
| | | | we don't need to run gc frequently
* refactor __del__ exception handler into PyErr_WriteUnraisableJeremy Hylton2000-09-011-1/+10
| | | | | add sanity check to gc: if an exception occurs during GC, call PyErr_WriteUnraisable and then call Py_FatalEror.
* apply patch #101362 by Vladimir MarangozovJeremy Hylton2000-08-311-33/+24
| | | | also initial static debug variable to 0
* Neil Schemenauer: GC enable(), disable(), isenabled() interface.Vladimir Marangozov2000-08-061-16/+76
| | | | | | Small stylistic changes by VM: - is_enabled() -> isenabled() - static ... Py_<func> -> static ... gc_<func>
generated by cgit v0.12 at 2024-12-04 20:58:56 (GMT)