美文网首页
大师兄的Python源码学习笔记(五十三): Python的内存

大师兄的Python源码学习笔记(五十三): Python的内存

作者: superkmi | 来源:发表于2022-02-04 11:05 被阅读0次

    大师兄的Python源码学习笔记(五十二): Python的内存管理机制(七)
    大师兄的Python源码学习笔记(五十四): Python的内存管理机制(九)

    五、Python中的垃圾收集

    • 由于在Python中,内存管理的主要手段是引用计数,而标记——清除分代收集只是为了打破循环引用而引入的补充技术。
    • 这意味着Python中的垃圾收集只关注可能会产生循环引用的对象。
    • 显然,像PyIntObjectPyStringObject这些对象是不会产生循环引用的,因为他们它们内部不可能持有对其它对象的引用。
    • Python中的循环引用总是发生在container对象之间,比如:listdictclassinstance等等。
    • 为了达到这一点,Python必须跟踪所创建的每一个container对象,并将这些对象组织到一个集合中,才能将垃圾收集的动作限制在这些对象上。
    • 实际上Python采用了一个双向链表,所有的container对象在创建之后,都会被插入到这个链表中。
    1. 可收集对象链表
    • 我们已经知道,任何一个Python对象都分为两部分:
    • 一部分是PyObject_HEAD
    • 另一部分是对象自身的数据。
    • 除此之外,为了将这个对象链入到Python内部的可收集对象链表中,成为一个可收集对象,还需要在PyObject_HEAD之前加入PyGC_Head
    Include/objimpl.h
    
    typedef union _gc_head {
        struct {
            union _gc_head *gc_next;
            union _gc_head *gc_prev;
            Py_ssize_t gc_refs;
        } gc;
        double dummy;  /* force worst-case alignment */
    } PyGC_Head;
    
    • 所以,对于Python所创建的可收集container对象,其内存分布与我们之前所了解的内存布局不同:
    Modules/gcmodule.c
    
    PyObject *
    _PyObject_GC_New(PyTypeObject *tp)
    {
        PyObject *op = _PyObject_GC_Malloc(_PyObject_SIZE(tp));
        if (op != NULL)
            op = PyObject_INIT(op, tp);
        return op;
    }
    
    Modules/gcmodule.c
    
    PyObject *
    _PyObject_GC_Malloc(size_t basicsize)
    {
        return _PyObject_GC_Alloc(0, basicsize);
    }
    
    Modules/gcmodule.c
    
    #define _PyGC_REFS_UNTRACKED                    (-2)
    #define GC_UNTRACKED                    _PyGC_REFS_UNTRACKED
    
    static PyObject *
    _PyObject_GC_Alloc(int use_calloc, size_t basicsize)
    {
        PyObject *op;
        PyGC_Head *g;
        size_t size;
        if (basicsize > PY_SSIZE_T_MAX - sizeof(PyGC_Head))
            return PyErr_NoMemory();
        size = sizeof(PyGC_Head) + basicsize;
        if (use_calloc)
            g = (PyGC_Head *)PyObject_Calloc(1, size);
        else
            g = (PyGC_Head *)PyObject_Malloc(size);
        if (g == NULL)
            return PyErr_NoMemory();
        g->gc.gc_refs = 0;
        _PyGCHead_SET_REFS(g, GC_UNTRACKED);
        _PyRuntime.gc.generations[0].count++; /* number of allocated GC objects */
        if (_PyRuntime.gc.generations[0].count > _PyRuntime.gc.generations[0].threshold &&
            _PyRuntime.gc.enabled &&
            _PyRuntime.gc.generations[0].threshold &&
            !_PyRuntime.gc.collecting &&
            !PyErr_Occurred()) {
            _PyRuntime.gc.collecting = 1;
            collect_generations();
            _PyRuntime.gc.collecting = 0;
        }
        op = FROM_GC(g);
        return op;
    }
    
    • 从上面代码中可以看到,当Python为可收集的container对象申请内存空间时,也为PyGC_Head申请/分配了内存空间,并且在container对象之前。
    • 此时,container对象的内存分布推测图如下:
    • 从上图可以看到container对象内存分为三部分:
    • PyGC_Head用于垃圾收集;
    • PyObject_Head是所有对象都有的头文件;
    • Container object包含container对象自身的数据。
    • PyGC_Head部分,除了两个用于建立链表结构的双向指针外,还有一个gc_ref,这个值被初始化为GC_UNTRACKED ,它对于垃圾收集是至关重要的。
    • 当垃圾收集机制运行期间,需要在一个可收集的container对象PyGC_Head部分和PyObject_HEAD部分来回转换。
    • 因此Python提供了一个对象在PyObject_HEADPyGC_Head两个地址之间的转换算法:
    Modules/gcmodule.c
    
    /* Get an object's GC head */
    #define AS_GC(o) ((PyGC_Head *)(o)-1)
    
    /* Get the object given the GC head */
    #define FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
    
    Include/objimpl.h
    
    #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
    
    • PyGC_Head中,出现了用于建立链表的两个指针,只有将创建的可收集container对象链接到Python内部维护的可收集对象链表中,Python的垃圾收集机制才能跟踪和处理这个container对象
    • 但实际上在创建可收集container对象之时,并没有立即将这个对象链接到链表之中。
    • 这个动作是发生在创建某个container对象的最后一步,以PySliceObject为例:
    Objects/sliceobject.c
    
    PyObject *
    PySlice_New(PyObject *start, PyObject *stop, PyObject *step)
    {
        PySliceObject *obj;
        if (slice_cache != NULL) {
            obj = slice_cache;
            slice_cache = NULL;
            _Py_NewReference((PyObject *)obj);
        } else {
            obj = PyObject_GC_New(PySliceObject, &PySlice_Type);
            if (obj == NULL)
                return NULL;
        }
    
        if (step == NULL) step = Py_None;
        Py_INCREF(step);
        if (start == NULL) start = Py_None;
        Py_INCREF(start);
        if (stop == NULL) stop = Py_None;
        Py_INCREF(stop);
    
        obj->step = step;
        obj->start = start;
        obj->stop = stop;
    
        _PyObject_GC_TRACK(obj);
        return (PyObject *) obj;
    }
    
    • 在创建container对象的最后一步,Python通过_PyObject_GC_TRACK将所创建的container对象链接到Python中的可收集对象链表中:
    Include/objimpl.h
    
    /* Tell the GC to track this object.  NB: While the object is tracked the
     * collector it must be safe to call the ob_traverse method. */
    #define _PyObject_GC_TRACK(o) do { \
        PyGC_Head *g = _Py_AS_GC(o); \
        if (_PyGCHead_REFS(g) != _PyGC_REFS_UNTRACKED) \
            Py_FatalError("GC object already tracked"); \
        _PyGCHead_SET_REFS(g, _PyGC_REFS_REACHABLE); \
        g->gc.gc_next = _PyGC_generation0; \
        g->gc.gc_prev = _PyGC_generation0->gc.gc_prev; \
        g->gc.gc_prev->gc.gc_next = g; \
        _PyGC_generation0->gc.gc_prev = g; \
        } while (0);
    
    • define _PyObject_GC_TRACK后,我们创建的container对象已经置于Python垃圾收集机制的掌控之中了。
    • 同样,Python还提供一个将container对象从链表中摘除的方法,它是define _PyObject_GC_TRACK的逆运算,这个方法在对象被销毁时调用:
    Include/objimpl.h
    
    /* Tell the GC to stop tracking this object.
     * gc_next doesn't need to be set to NULL, but doing so is a good
     * way to provoke memory errors if calling code is confused.
     */
    #define _PyObject_GC_UNTRACK(o) do { \
        PyGC_Head *g = _Py_AS_GC(o); \
        assert(_PyGCHead_REFS(g) != _PyGC_REFS_UNTRACKED); \
        _PyGCHead_SET_REFS(g, _PyGC_REFS_UNTRACKED); \
        g->gc.gc_prev->gc.gc_next = g->gc.gc_next; \
        g->gc.gc_next->gc.gc_prev = g->gc.gc_prev; \
        g->gc.gc_next = NULL; \
        } while (0);
    
    • 在Python运行的某个时刻,所建立起来的可收集对象链表如下:


    相关文章

      网友评论

          本文标题:大师兄的Python源码学习笔记(五十三): Python的内存

          本文链接:https://www.haomeiwen.com/subject/hojtkrtx.html