1. 09 Kas, 2002 1 kayıt (commit)
  2. 09 Agu, 2002 1 kayıt (commit)
  3. 07 Tem, 2002 2 kayıt (commit)
    • Tim Peters's avatar
      Trashcan cleanup: Now that cyclic gc is always there, the trashcan · 803526b9
      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.
      803526b9
    • Tim Peters's avatar
      Removed WITH_CYCLE_GC #ifdef-ery. Holes: · 943382c8
      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.
      943382c8
  4. 04 Tem, 2002 1 kayıt (commit)
  5. 02 Tem, 2002 3 kayıt (commit)
    • Tim Peters's avatar
      visit_decref(): Added another assert. · aab713bd
      Tim Peters yazdı
      aab713bd
    • Tim Peters's avatar
      Finished transitioning to using gc_refs to track gc objects' states. · 6fc13d95
      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.
      6fc13d95
    • Tim Peters's avatar
      Reserved another gc_refs value for untracked objects. Every live gc · ea405639
      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.
      ea405639
  6. 01 Tem, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's · 19b74c78
      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.
      19b74c78
  7. 30 Haz, 2002 2 kayıt (commit)
    • Tim Peters's avatar
      visit_decref(): Two optimizations. · 93cd83e4
      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.
      93cd83e4
    • Tim Peters's avatar
      SF bug #574132: Major GC related performance regression · 8839617c
      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>).
      8839617c
  8. 28 Haz, 2002 1 kayıt (commit)
  9. 13 Haz, 2002 1 kayıt (commit)
  10. 06 Haz, 2002 1 kayıt (commit)
  11. 21 May, 2002 1 kayıt (commit)
  12. 04 May, 2002 1 kayıt (commit)
    • Neil Schemenauer's avatar
      Move all data for a single generation into a structure. The set of · 2880ae53
      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.
      2880ae53
  13. 28 Nis, 2002 1 kayıt (commit)
  14. 12 Nis, 2002 1 kayıt (commit)
  15. 29 Mar, 2002 1 kayıt (commit)
  16. 28 Mar, 2002 1 kayıt (commit)
  17. 22 Mar, 2002 2 kayıt (commit)
  18. 29 Ock, 2002 1 kayıt (commit)
  19. 02 Ara, 2001 2 kayıt (commit)
  20. 29 Kas, 2001 1 kayıt (commit)
  21. 24 Kas, 2001 1 kayıt (commit)
  22. 01 Kas, 2001 3 kayıt (commit)
  23. 31 Eki, 2001 1 kayıt (commit)
  24. 12 Eki, 2001 1 kayıt (commit)
  25. 11 Eki, 2001 1 kayıt (commit)
    • Tim Peters's avatar
      SF bug [#467145] Python 2.2a4 build problem on HPUX 11.0. · 9e4ca10c
      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).
      9e4ca10c
  26. 07 Eki, 2001 1 kayıt (commit)
  27. 06 Eki, 2001 3 kayıt (commit)
    • Tim Peters's avatar
      _PyObject_VAR_SIZE: always round up to a multiple-of-pointer-size value. · 6d483d34
      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?
      6d483d34
    • Tim Peters's avatar
      Repaired the debug Windows deaths in test_descr, by allocating enough · 406fe3b1
      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>.
      406fe3b1
    • Tim Peters's avatar
      _PyObject_GC_Malloc(): split a complicated line in two. As is, there was · 8c18f258
      Tim Peters yazdı
      no way to talk the debugger into showing me how many bytes were being
      allocated.
      8c18f258
  28. 30 Agu, 2001 1 kayıt (commit)
    • Neil Schemenauer's avatar
      Make more things internal to this file. Remove · 43411b56
      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).
      43411b56
  29. 10 Agu, 2001 1 kayıt (commit)
  30. 09 Agu, 2001 1 kayıt (commit)