1. 09 May, 2010 1 kayıt (commit)
  2. 28 Eyl, 2009 1 kayıt (commit)
    • Kristján Valur Jónsson's avatar
      http://bugs.python.org/issue6836 · 02ca57ce
      Kristján Valur Jónsson yazdı
      The debug memory api now keeps track of which external API (PyMem_* or PyObject_*) was used to allocate each block and treats any API violation as an error.  Added separate _PyMem_DebugMalloc functions for the Py_Mem API instead of having it use the _PyObject_DebugMalloc functions.
      02ca57ce
  3. 23 Mar, 2009 1 kayıt (commit)
    • Antoine Pitrou's avatar
      Issue #4688: Add a heuristic so that tuples and dicts containing only · f8387af2
      Antoine Pitrou yazdı
      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)
      f8387af2
  4. 19 Ara, 2007 1 kayıt (commit)
  5. 21 Tem, 2007 1 kayıt (commit)
  6. 15 Nis, 2006 1 kayıt (commit)
    • Tim Peters's avatar
      frame_traverse(): Use the standard Py_VISIT macro. · de2acf65
      Tim Peters yazdı
      Py_VISIT:  cast the `op` argument to PyObject* when calling
      `visit()`.  Else the caller has to pay too much attention to
      this silly detail (e.g., frame_traverse needs to traverse
      `struct _frame *` and `PyCodeObject *` pointers too).
      de2acf65
  7. 26 Mar, 2006 1 kayıt (commit)
    • Tim Peters's avatar
      Years in the making. · c9d78aa4
      Tim Peters yazdı
      objimpl.h, pymem.h:  Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE}
      to PyObject_{Free, FREE} in a release build.  They're aliases for the
      system free() now.
      
      _subprocess.c/sp_handle_dealloc():  Since the memory was originally
      obtained via PyObject_NEW, it must be released via PyObject_FREE (or
      _DEL).
      
      pythonrun.c, tokenizer.c, parsermodule.c:  I lost count of the number of
      PyObject vs PyMem mismatches in these -- it's like the specific
      function called at each site was picked at random, sometimes even with
      memory obtained via PyMem getting released via PyObject.  Changed most
      to use PyObject uniformly, since the blobs allocated are predictably
      small in most cases, and obmalloc is generally faster than system
      mallocs then.
      
      If extension modules in real life prove as sloppy as Python's front
      end, we'll have to revert the objimpl.h + pymem.h part of this patch.
      Note that no problems will show up in a debug build (all calls still go
      thru obmalloc then). Problems will show up only in a release build, most
      likely segfaults.
      c9d78aa4
  8. 04 Mar, 2006 1 kayıt (commit)
  9. 01 Mar, 2006 1 kayıt (commit)
  10. 16 Şub, 2006 1 kayıt (commit)
  11. 15 Şub, 2006 1 kayıt (commit)
  12. 26 Ock, 2006 1 kayıt (commit)
  13. 22 Tem, 2005 1 kayıt (commit)
  14. 15 Tem, 2004 1 kayıt (commit)
  15. 14 Tem, 2004 1 kayıt (commit)
  16. 17 Nis, 2003 1 kayıt (commit)
  17. 12 Agu, 2002 1 kayıt (commit)
  18. 07 Tem, 2002 1 kayıt (commit)
  19. 02 Tem, 2002 2 kayıt (commit)
    • 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
  20. 04 May, 2002 1 kayıt (commit)
  21. 28 Nis, 2002 1 kayıt (commit)
    • Tim Peters's avatar
      Moving pymalloc along. · 8b078f95
      Tim Peters yazdı
      As threatened, PyMem_{Free, FREE} also invoke the object deallocator now
      when pymalloc is enabled (well, it does when pymalloc isn't enabled too,
      but in that case "the object deallocator" is plain free()).
      
      This is maximally backward-compatible, but it leaves a bitter aftertaste.
      
      Also massive reworking of comments.
      8b078f95
  22. 13 Nis, 2002 1 kayıt (commit)
  23. 12 Nis, 2002 2 kayıt (commit)
  24. 28 Mar, 2002 1 kayıt (commit)
  25. 22 Mar, 2002 1 kayıt (commit)
  26. 18 Mar, 2002 2 kayıt (commit)
  27. 28 Şub, 2002 1 kayıt (commit)
  28. 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
  29. 07 Eki, 2001 1 kayıt (commit)
  30. 06 Eki, 2001 2 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
  31. 02 Eki, 2001 1 kayıt (commit)
    • Guido van Rossum's avatar
      Add Garbage Collection support to new-style classes (not yet to their · 048eb75c
      Guido van Rossum yazdı
      instances).
      
      Also added GC support to various auxiliary types: super, property,
      descriptors, wrappers, dictproxy.  (Only type objects have a tp_clear
      field; the other types are.)
      
      One change was necessary to the GC infrastructure.  We have statically
      allocated type objects that don't have a GC header (and can't easily
      be given one) and heap-allocated type objects that do have a GC
      header.  Giving these different metatypes would be really ugly: I
      tried, and I had to modify pickle.py, cPickle.c, copy.py, add a new
      invent a new name for the new metatype and make it a built-in, change
      affected tests...  In short, a mess.  So instead, we add a new type
      slot tp_is_gc, which is a simple Boolean function that determines
      whether a particular instance has GC headers or not.  This slot is
      only relevant for types that have the (new) GC flag bit set.  If the
      tp_is_gc slot is NULL (by far the most common case), all instances of
      the type are deemed to have GC headers.  This slot is called by the
      PyObject_IS_GC() macro (which is only used twice, both times in
      gcmodule.c).
      
      I also changed the extern declarations for a bunch of GC-related
      functions (_PyObject_GC_Del etc.): these always exist but objimpl.h
      only declared them when WITH_CYCLE_GC was defined, but I needed to be
      able to reference them without #ifdefs.  (When WITH_CYCLE_GC is not
      defined, they do the same as their non-GC counterparts anyway.)
      048eb75c
  32. 03 Eyl, 2001 1 kayıt (commit)
  33. 29 Agu, 2001 1 kayıt (commit)
  34. 03 Agu, 2001 1 kayıt (commit)
  35. 02 Agu, 2001 1 kayıt (commit)
  36. 22 Mar, 2001 1 kayıt (commit)
    • Fred Drake's avatar
      A small change to the C API for weakly-referencable types: Such types · 4e262a96
      Fred Drake yazdı
      must now initialize the extra field used by the weak-ref machinery to
      NULL themselves, to avoid having to require PyObject_INIT() to check
      if the type supports weak references and do it there.  This causes less
      work to be done for all objects (the type object does not need to be
      consulted to check for the Py_TPFLAGS_HAVE_WEAKREFS bit).
      4e262a96