- 09 Kas, 2002 1 kayıt (commit)
-
-
Martin v. Löwis yazdı
-
- 09 Agu, 2002 1 kayıt (commit)
-
-
Guido van Rossum yazdı
for a __del__ attribute, to see if there's a finalizer.
-
- 07 Tem, 2002 2 kayıt (commit)
-
-
Tim Peters yazdı
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.
-
Tim Peters yazdı
+ I'm not sure what to do about configure.in. Left it alone. + Ditto pyexpat.c. Fred or Martin will know what to do.
-
- 04 Tem, 2002 1 kayıt (commit)
-
-
Michael W. Hudson yazdı
-
- 02 Tem, 2002 3 kayıt (commit)
-
-
Tim Peters yazdı
-
Tim Peters yazdı
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.
-
Tim Peters yazdı
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.
-
- 01 Tem, 2002 1 kayıt (commit)
-
-
Tim Peters yazdı
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.
-
- 30 Haz, 2002 2 kayıt (commit)
-
-
Tim Peters yazdı
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.
-
Tim Peters yazdı
"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>).
-
- 28 Haz, 2002 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
collected one should be zeroed.
-
- 13 Haz, 2002 1 kayıt (commit)
-
-
Martin v. Löwis yazdı
-
- 06 Haz, 2002 1 kayıt (commit)
-
-
Jeremy Hylton yazdı
-
- 21 May, 2002 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
-
- 04 May, 2002 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
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.
-
- 28 Nis, 2002 1 kayıt (commit)
-
-
Tim Peters yazdı
_PyObject_GC_NewVar: Could call PyObject_INIT_VAR likewise. Bugfix candidate.
-
- 12 Nis, 2002 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
compatibility function. Make PyObject_GC_Track and PyObject_GC_UnTrack functions instead of trivial macros wrapping functions. Provide binary compatibility functions.
-
- 29 Mar, 2002 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
-
- 28 Mar, 2002 1 kayıt (commit)
-
-
Guido van Rossum yazdı
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!
-
- 22 Mar, 2002 2 kayıt (commit)
-
-
Neil Schemenauer yazdı
-
Neil Schemenauer yazdı
-
- 29 Ock, 2002 1 kayıt (commit)
-
-
Neal Norwitz yazdı
-
- 02 Ara, 2001 2 kayıt (commit)
-
-
Martin v. Löwis yazdı
-
Martin v. Löwis yazdı
-
- 29 Kas, 2001 1 kayıt (commit)
-
-
Martin v. Löwis yazdı
-
- 24 Kas, 2001 1 kayıt (commit)
-
-
Martin v. Löwis yazdı
-
- 01 Kas, 2001 3 kayıt (commit)
-
-
Tim Peters yazdı
"complicated_bool".
-
Neil Schemenauer yazdı
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.
-
Guido van Rossum yazdı
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.)
-
- 31 Eki, 2001 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
SF bug 476129: "gc.collect sometimes hangs".
-
- 12 Eki, 2001 1 kayıt (commit)
-
-
Guido van Rossum yazdı
up GCC warnings.
-
- 11 Eki, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
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).
-
- 07 Eki, 2001 1 kayıt (commit)
-
-
Tim Peters yazdı
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.
-
- 06 Eki, 2001 3 kayıt (commit)
-
-
Tim Peters yazdı
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?
-
Tim Peters yazdı
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>.
-
Tim Peters yazdı
no way to talk the debugger into showing me how many bytes were being allocated.
-
- 30 Agu, 2001 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
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).
-
- 10 Agu, 2001 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
of PyList_Append.
-
- 09 Agu, 2001 1 kayıt (commit)
-
-
Neil Schemenauer yazdı
get_referents, and is not yet documented in the library manual). Suggestions for a better name welcome.
-