Closure Variablen bzw. Blockscoping

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Kurt Z
User
Beiträge: 23
Registriert: Samstag 17. Mai 2008, 17:43

danke ich bin wieder schlauer offenbar hat Python ein zweistufigen GC, neben der Refrencecounter-Methode läuft in Intervallen ein Mark&Sweep.

Allerdings verstehe ich die Kausalität zwischen Memory Leaks und Blockscopes immer noch nicht.

Naja morgen fliegen wir weiter und ich hab 3 Wochen Internet-Entzug ... :D
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Kurt Z hat geschrieben:Allerdings verstehe ich die Kausalität zwischen Memory Leaks und Blockscopes immer noch nicht.
In Ruby/JavaScript lässt der Interpreter alle übergeordneten Frames im Speicher, selbst wenn die Variablen dort nicht genutzt werden. In Python erkennt der Intepreter, welche Variablen tatsächlich referenziert werden und nur diese bleiben in den cell-vars gespeichert. Wenn du nicht auf self zugreifst stirbt dann zb die Klasse.

Das hier zeigt das ganz gut:

Code: Alles auswählen

>>> class Foo(object):
...  def make_closure(self, num):
...   return lambda: num
... 
>>> foo = Foo()
>>> funcs = map(foo.make_closure, range(10))
>>> sys.getrefcount(foo)
2
In Ruby kann ich leider vom GC keine Refernzen finden lassen, aber es wären 11 auf foo weil jede Closure via self auf die Instanz zugreift. Das merkt man sehr schnell, wenn man mit Blocks anfängt selber auf Klassen oder Instanzen rumzupatchen und die Anwendung plötzlich einen Speicherverbrauch von nix Gutem hat. Das Problem tritt vor allem in vielen Rails Anwendungen auf, kann man wunderbar nach googlen :)
TUFKAB – the user formerly known as blackbird
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Memoryleaks entstehen meines Wissens wenn die Garbage Collection eine Variable nicht entsorgen kann, weil die Variable nur anscheinend noch gebraucht wird. Z.B. bei Ringbezügen
Dies ist so falsch bzw. nur richtig für reference counting, was kein echter garbage collection Algorithmus ist. Diese (z.B. die Klassiker stop&copy oder mark&sweep) haben mit Ringbezügen keine Probleme.

Stefan
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Speicherlecks entstehen meines Wissens, wenn ein Progammierer unabsichtlich Referenzen auf Objekte belässt und davon ausgeht, wieder eine saubere Ausgangslage für den nächsten Schritt zu haben. Das gilt sowohl für Implementierungen von Programmiersprachen als auch Programmen selbst.

Ich kann mir gut vorstellen, dass man auch in Python Speicherlecks (im Sinne von Programmen, die mit zunehmender Laufzeit immer mehr Speicher benötigen) schaffen kann, wenn man sich Mühe gibt ;)

OTOH, IANALowlevel-Experte.
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Y0Gi hat geschrieben:Speicherlecks entstehen meines Wissens, wenn ein Progammierer unabsichtlich Referenzen auf Objekte belässt und davon ausgeht, wieder eine saubere Ausgangslage für den nächsten Schritt zu haben. Das gilt sowohl für Implementierungen von Programmiersprachen als auch Programmen selbst.
Sowas z.B. http://developers.slashdot.org/article. ... 17/0552247 :) Ist zwar kein Python, aber genau das Problem auf das du anspielst.
Antworten