The reference count has the obvious flaw of the loop count, so why should python use reference counting instead of tag cleanup?
Reply content:
The greatest benefit of reference counting is recovery in time: The moment the reference count of an object is zeroed is the moment it becomes garbage, and the moment it is recycled. And this formal mark-sweep the disadvantage of the tracing GC algorithm: After an object becomes garbage, it remains in memory for a period of time (floating garbage) until the next GC is cleared out.
The GC design for Python is that reference counting is used for objects that do not internally contain references to other objects (such as strings, numeric types, and so on) because they are not likely to produce circular references at all. Mark-sweep is used for objects that may produce circular references, such as List, Map, and so on. So my understanding is that the GC design of Python, to some extent, combines the advantages of two types of GC algorithms-that is, the integrity of the recovery and the timeliness of recovery.
Update
The above description is biased, the review of the R large supplement to paste up:
The
reference count, such as list, map, set, is also working. Mark-sweep is just a backup.
The entire reference counting mechanism is embedded in the CEVAL.C, and all objects have to be tossed into it.
In other words, not the list is not referenced, but the list's reference count is naturally released by the reference counting mechanism if it drops naturally to 0, otherwise it will be processed when the cycle GC starts.
However, the use of reference counting to improve the timeliness of recycling is still established. This is a design choice. It's good to be happy with CPython.
There are many other Python implementations that do not have a reference count and are not happy to use them (escaping
In addition, the reference count of CPython is Mark-sweep backed up, not afraid of circular references.
The official website explains the choice (but it doesn't really say anything ...). ）： https:// docs.python.org/2/faq/d esign.html#how-does-python-manage-memory
The details of the Python memory management depend on the implementation.
the standard C implementation of Python uses reference counting to detect inaccessible objects, and another mechanism To collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and de Letes the objects involved.The GC module provides functions to perform a garbage collection, obtain debugging statistics, and tune the collector ' s PA Rameters.
In the absence of Circularities and tracebacks, Python programs don't need to manage memory explicitly.
Why doesn ' t Python with a more traditional garbage collection scheme? For one thing, the is not a-C standard feature and hence it's not portable. (Yes, we know about the Boehm GC Library.) It has bits of assembler code for the most common platforms, not for all of them, and although it's mostly transparent, it is N ' t completely transparent; Patches is required to get Python to work with it.)
...
Traditional GC also becomes a problem when Python was embedded into other applications. While in a standalone Python it's fine to replace the standard malloc () and free () with versions provided by the GC Librar Y, an application embedding Python could want to has its own substitute for malloc () and free (), and could not be want Python's. Right now, the Python works with anything, this implements malloc () and free () properly.
Then look at this article to introduce the newer Python "Mark-swep GC" in fact, or "generational": / http patshaughnessy.net/2013 /10/30/generational-gc-in-python-and-ruby
Then JavaScript is not necessarily mark-sweep ... Language norms are not so stipulated, the actual implementation is not all with mark-sweep. Python now also uses reference counting because it was a long time ago that python was so old-fashioned that it was patched up on the reference count, and it just kept hitting the patch.
Garbage Collection for Python
First answer the next question, why Python should use it, because the author is willing to
If the main question is to ask, "better" is not a better choice to clear the mark, then you can say a little more
First of all, this premise is not tenable, academic point of view can see "garbage collection" This book, which uses "no silver bullet" to describe the choice of algorithms, that is, no better than who, only in the specific scenario who is more suitable for the problem
The greatest benefit of reference counting is real-time, followed by avoiding excessive over-allocation without circular references, and memory not wasting
The importance of this real-time, I guess in some scenarios, more important than most people think, specifically can read my blog article, this is also just said other will stop world GC algorithm shortcomings when written:
Avalanche effect-Xtlisk's column
(article is a series, to the language theory is interested in can communicate more:)
Moreover, the circular reference is really a big flaw, this has always been controversial, some people use statistics to prove that most of the code and objects do not produce circular references, with code to avoid it, but also some people say that in a particular scenario will be very much (such as the game's role, equipment, the relationship between the buff), is generally considered to be a major flaw, but it is not impossible to solve
Second, ask why before the first look is not, the PY Standard Edition is really mainly used reference counting, but other implementations are not so, such as Jython directly depends on the JVM. And the standard version does not ignore the circular reference this flaw, in 2.5 introduced the GC module, for circular reference with local mark Sweep, note is the local mark sweep rather than the ordinary Mark Sweep, although the same thought, but there is a special point, specific can see "garbage collection" this book
In fact, the PY with ref count is a flaw, to a certain degree even to a large extent caused the Gil this mechanism, the number of people who spit Groove Gil very much, but very little notice with the GC's choice about Python was just written out when the Mark purge is not so much the way it is today. Java also comes from a reference count. Objectivec is also using reference counting.
Most strategies have two sides, for example, you should also look at the benefits of reference counting:
- If the programmer can do not loop reference, then the efficiency is very high, will not bring the VM downtime AH
- Again, why use a reference count? It's easy, you can write one yourself right after you hear it. Easy to understand, you can say it in a few minutes. You can compare markers to clear
When Python grows big enough to start worrying about reference counting like Java, the tragedy happens, and it doesn't seem to change. I believe there are still a lot of people working to get rid of the reference count in Python today.
Balabala's Ramble
Python memory management compared with other language runtime
When you debug a Java program, trigger a JVM GC in the pending state, don't you feel stuck? Why is JavaScript using a clearly flawed tag purge instead of a python-like reference count? Why is JavaScript using a clearly flawed tag purge instead of a python-like reference count?
Tag cleanup has a noticeable flaw with poor performance, so why is JavaScript using tag cleanup instead of reference counting? Reference counting makes it easy for third-party expansion modules to participate in managing CPython memory. Third-party expansion modules can easily save CPython pointers without worrying about the memory that the pointer is pointing to is freed.
