Author: Matti Picus <matti.pi...@gmail.com> Branch: extradoc Changeset: r5926:b52d3e5d3a0d Date: 2018-12-23 13:08 +0200 http://bitbucket.org/pypy/extradoc/changeset/b52d3e5d3a0d/
Log: edit the blog post diff --git a/blog/draft/2018-12-gc-disable/gc-disable.rst b/blog/draft/2018-12-gc-disable/gc-disable.rst --- a/blog/draft/2018-12-gc-disable/gc-disable.rst +++ b/blog/draft/2018-12-gc-disable/gc-disable.rst @@ -7,48 +7,49 @@ (which, by the way, is a very cool and geeky place where to work_, in case you are interested). -The PyPy VM manages the memory using a generational, moving Garbage Collector: -periodically, the GC scans the whole heap to find unreachable objects and +The PyPy VM manages memory using a generational, moving Garbage Collector. +Periodically, the GC scans the whole heap to find unreachable objects and frees the corresponding memory. Although at a first look this strategy might sound expensive, in practice the total cost of memory management is far less -than e.g. on CPython, which is based on reference counting. This happens for -various reasons, the most important ones being that allocation is very fast -(especially compared to malloc-based allocators), and deallocation of objects -which die young is basically for free. More information about the PyPy GC is -available here_. +than e.g. on CPython, which is based on reference counting. While maybe +counter-intuitive, the main advantage of a non-refcount strategy is +that allocation is very fast (especially compared to malloc-based allocators), +and deallocation of objects which die young is basically for free. More +information about the PyPy GC is available here_. As we said, the total cost of memory managment is less on PyPy than on CPython, and it's one of the reasons why PyPy is so fast. However, one big disadvantage is that while on CPython the cost of memory management is spread -all over the execution of the program, on PyPy it is concentrated when the GC +all over the execution of the program, on PyPy it is concentrated into GC runs, causing observable pauses which interrupt the execution of the user program. To avoid excessively long pauses, the PyPy GC has been using an `incremental -strategy since 2013`_: the GC runs as a series of "steps", letting the user +strategy`_ since 2013. The GC runs as a series of "steps", letting the user program to progress between each step. The following chart shows the behavior of a real-world, long-running process: .. image:: gc-timing.png -The orange line shows the amount of memory used by the program, which +The orange line shows the total memory used by the program, which increases linearly while the program progresses. Every ~5 minutes, the GC -kicks in and the memory usage drops from ~5.2GB to ~2.8GB (this is not a -casual ratio, it is controlled by the PYPY_GC_MAJOR_COLLECT_ env variable). +kicks in and the memory usage drops from ~5.2GB to ~2.8GB (this is controlled +by the PYPY_GC_MAJOR_COLLECT_ env variable). The purple line shows aggregated data about the GC timing: the whole collection takes ~1400 individual steps over the course of ~1 minute: each point represent the **maximum** time a single step took during the past 10 seconds. Most steps take ~10-20 ms, although we see a horrible peak of ~100 ms towards the end. We have not investigated yet what it is caused by, but we -suspect it is related with the deallocation of raw objects. +suspect it is related to the deallocation of raw objects. -This is clearly a problem for systems where it is important to respond to -certain events with a latency which is both low and consistent: the GC kicks -in at the wrong time, it might causes unacceptable pauses during the response. +These multi-millesecond pauses are a problem for systems where it is important +to respond to certain events with a latency which is both low and consistent. +The GC kicks in at the wrong time, it might causes unacceptable pauses during +the collection cycle. -Let's look again at our real-world example: this is a system which +Let's look again at our real-world example. This is a system which continuously monitors an external stream; when a certain event occurs, we want to take an action. The following chart shows the maximum time it takes to complete one of such actions, aggregated every minute: @@ -63,12 +64,13 @@ The work I did in the ``gc-disable`` branch aims to fix this problem by introducing `two new features`_ to the ``gc`` module: - - ``gc.disable()``, which used to simply inhibit the execution of - finalizers, now disables the GC major collections for real. After a call - to it, you will see the memory usage to grow indefinitely. + - ``gc.disable()``, which previously only inhibited the execution of + finalizers without actually touching the GC, now disables the GC major + collections. After a call to it, you will see the memory usage grow + indefinitely. - ``gc.collect_step()`` is a new function which you can use to manually - execute a single incremental step. + execute a single incremental GC collection step. Combining these two functions, it is possible to take control of the GC to make sure it runs only when it is acceptable to do so. For an example of @@ -91,11 +93,13 @@ available in the nightly builds of PyPy, and will be included in the next release: take this as a Christmas present :) +Antonio Cuni and the PyPy team + .. _`Gambit Research`: https://www.gambitresearch.com/ .. _work: https://www.gambitresearch.com/jobs.html .. _here: https://pypy.readthedocs.io/en/latest/gc_info.html#incminimark -.. _`incremental strategy since 2013`: https://morepypy.blogspot.com/2013/10/incremental-garbage-collector-in-pypy.html +.. _`incremental strategy`: https://morepypy.blogspot.com/2013/10/incremental-garbage-collector-in-pypy.html .. _PYPY_GC_MAJOR_COLLECT: https://pypy.readthedocs.io/en/latest/gc_info.html#environment-variables .. _`two new features`: https://pypy.readthedocs.io/en/latest/gc_info.html#semi-manual-gc-management .. _`Custom GC`: https://bitbucket.org/antocuni/pypytools/src/0273afc3e8bedf0eb1ef630c3bc69e8d9dd661fe/pypytools/gc/custom.py?at=default&fileviewer=file-view-default _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
