Ah, schön zu hören Das heißt das es nun Quasi zwei GCs in Python gibt oder der alte aufgebohrt wurde um das Erreichbarkeitsproblem im Graphen zu behandeln? Weil, der eigentliche GC basiert doch immer noch auf einer Referenzzählung, was man auch in den Python Extensions sehen kann (XINCREF, XDECREF).birkenfeld hat geschrieben: Da hast du wohl was falsch verstanden. Das, was im Kontext von CPython als "GC" bezeichnet wird, ist der in IIRC 2.0 neue Cyclic Garbage Collector, der eben genau deswegen eingeführt wurde, weil zyklische Referenzen vorher Probleme machten.
[/quote]
Ja, reference counting ist das hauptsächliche memory management. Der zyklische GC springt nur von Zeit zu Zeit an und kümmert sich um zirkuläre Referenzen.
Nein, auf die Schnelle nicht. Es müsste sich allerdings in den python-dev-Archiven einiges finden lassen aus der Zeit, in der der GC eingebaut wurde (um 2000 herum).Hättest du vielleicht einen Link bezüglich des GCs von Python, wo die Funktionsweise genau spezifiziert ist?
Da ich damals nicht dabei war, kann ich nur vermuten: Reference counting funktioniert soweit ja einwandfrei und schnell. Es ermöglicht deterministische Destruktion, wenn man alle Referenzen kennt. Das Hinzufügen des zyklischen GC war wahrscheinlich auch wesentlich einfacher, als das gesamte memory management auszutauschen.Mal "eine" Frage, da du ja ein Dev im Core Team bist:
1. Warum hat man sich gegen einen Mark-and-Sweep entschieden bzw. nicht in betrachte gezogen? Die von mir im ersten Post Zitierte Begründung kann es doch irgendwie nicht sein.
Nein, solange keiner wirkliche Gründe und einen Patch liefert.2. Ist für Py3K eine Reformierung des Python GCs geplant? Eventuell Mark-and-Sweep