Hallo,
wenn ein Objekt andere Objekte (also nicht nur Referenzen, sondern echt wie geschachtelte Hashes), werden diese Objekte dann auch zerstört wenn das Master-Objekt zerstört (undef) wird?
my $a = new A; my $b = new B;
$a->b($b); undef $a;
$b ist immer noch da, oder?
Oder muss ich rekursiv durch $a krabbeln um alle Unterobjekte zu zerstören? Die Applikation wird über SOAP angesprochen und wir haben den Verdacht, dass diese sich etwas merkwürdig verhält. Aller paar Tage wird innerhalb ein paar Stunden der Speicher zugekracht, bis der Kernel die Notbremse zieht. Bis dahin schein lt. free alles normal. Eigentlich kann es ja nicht mit obiger Frage zusammenhängen, aber man weiss ja nie ....
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
wenn ein Objekt andere Objekte (also nicht nur Referenzen, sondern echt wie geschachtelte Hashes), werden diese Objekte dann auch zerstört wenn das Master-Objekt zerstört (undef) wird?
my $a = new A; my $b = new B;
$a->b($b); undef $a;
$b ist immer noch da, oder?
$b ist solange noch da, wie es noch irgendwo bekannt ist. Wenn niemand mehr $b kennt, außer $a, dann wird es mit garbage collected, wenn $a verschwindet. Also halbwegs klassische Garbage-Collection.
Oder muss ich rekursiv durch $a krabbeln um alle Unterobjekte zu zerstören?
Mußt Du nicht, wenn nichts anderes mehr auf $b zeigt.
Die Applikation wird über SOAP angesprochen und wir haben den Verdacht, dass diese sich etwas merkwürdig verhält. Aller paar Tage wird innerhalb ein paar Stunden der Speicher zugekracht, bis der Kernel die Notbremse zieht.
Der Garbage-Collector könnte z.B. über Umwege wieder auf sich selbst verweisende Strukturen nicht als einen geschlossenen Ring von "Mülldaten" erkennen. Ist nicht ausgeschlossen, daß das passiert.
Ich bin nicht 100% fit in den Details, google mal nach Perl, FAQ und Garbage Collection. Hier scheint z.B. was zu stehen:
http://www.perl.com/doc/FAQs/FAQ/oldfaq-html/Q4.19.html
GreetinX Steffen
Am 12. November 2003 schrieb Steffen Schwigon:
Der Garbage-Collector könnte z.B. über Umwege wieder auf sich selbst verweisende Strukturen nicht als einen geschlossenen Ring von "Mülldaten" erkennen. Ist nicht ausgeschlossen, daß das passiert.
Ja, zyklische Referenzen kann perl wohl nicht auflösen, d. h. dass
my $a; my $b = $a; $a = $b;
am Ende des Blocks nicht freigegeben wird. Man braucht rechtzeitig noch ein
undef $a;
Obige Struktur sieht auch im Debugger ganz hübsch aus.
Torsten
On Wed, Nov 12, 2003 at 03:31:28PM +0100, Jens Puruckherr wrote:
wenn ein Objekt andere Objekte (also nicht nur Referenzen, sondern echt wie geschachtelte Hashes), werden diese Objekte dann auch zerstört wenn das Master-Objekt zerstört (undef) wird?
my $a = new A; my $b = new B;
$a->b($b); undef $a;
$b ist immer noch da, oder?
Hier: Ja. Denn Du hast ja noch $b. Solange es noch eine Referenz auf das Objekt gibt ($b ist in diesem Sinne auch eine), solange wird der Speicher, den $b belegt, nicht freigegeben.
Ein undef $b wird das angelegte Objekt zerstören, *wenn* Du Dir in $a->b($b) Dir nicht zufällig eine Referenz auf das erwähnte Objekt gemerkt hast.
Best regards from Dresden Viele Gruesse aus Dresden Heiko Schlittermann
lug-dd@schlittermann.de writes:
Hier: Ja. Denn Du hast ja noch $b. Solange es noch eine Referenz auf das Objekt gibt ($b ist in diesem Sinne auch eine), solange wird der Speicher, den $b belegt, nicht freigegeben.
Ein undef $b wird das angelegte Objekt zerstören, *wenn* Du Dir in $a->b($b) Dir nicht zufällig eine Referenz auf das erwähnte Objekt gemerkt hast.
Also, wenn ich nach
$a->b($b)
ein undef $b mache, existiert es dennoch als Teil von $a. Ein undef $a räumt dann restlos auf. Habe ich das so richtig kapiert? Da ich alle Unterobjekte immer in einem Hauptobjekt mit durch die Klassen hiefe, wäre das wohl dann der schlaue Weg, zum Schluss sauber aufzuräumen?
- Unterobjekt erzeugen - in Haupobjekt referenzieren - Unterobjekt zerstören - zum Schluss Hauptobjekt zerstören
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
Also, wenn ich nach
$a->b($b)
ein undef $b mache, existiert es dennoch als Teil von $a.
Ja. (Vorausgesetzt, Du weist es in der Funktion b() tatsächlich irgendeiner Variablen o.ä. zu, klar. Aber davon gehen wir ja alle aus.)
Ein undef $a räumt dann restlos auf.
Nicht zwangsweise unmittelbar. Die Entscheidung trifft der Garbage-Collector. Ich weiß nicht, wie genau das Teil bei Perl arbeitet.
Eigentlich sollte es also schon so funktionieren, aber da gibt's sicher noch subtile Ausnahmemöglichkeiten, die Dein Problem erklären können, falls es noch immer besteht.
Das Grunddilemma sind z.B. rekursive Datenstrukturen. Bei denen mußt Du AFAIK nachhelfen.
Habe ich das so richtig kapiert? Da ich alle Unterobjekte immer in einem Hauptobjekt mit durch die Klassen hiefe, wäre das wohl dann der schlaue Weg, zum Schluss sauber aufzuräumen?
- Unterobjekt erzeugen
- in Haupobjekt referenzieren
- Unterobjekt zerstören
- zum Schluss Hauptobjekt zerstören
Eigentlich genau nicht. :-)
Genau das soll der Garbage Collector eigentlich übernehmen, dazu ist er ja da. Das Zerstören von $a sollte reichen. Sonst wäre es C-like und für Perl-Geschmack viel zu mühselig.
Es wäre aber eine Methode zum Aufräumen, falls Du Dir eine rekursive Datenstruktur im Speicher aufgebaut hast, die der Garbage Collector beim Suchen nach Müll nicht erkennt. Wenn Dein $a und $b irgendwie nicht so trivial sind, wie es in dem Minimalbeispiel scheint.
Ob so ein Konstrukt bei Dir vorliegt, müßte man genauer untersuchen.
Im letzten Abschnitt von
http://www.perldoc.com/perl5.8.0/pod/perlobj.html
steht bissel was zu dem Thema und es gibt dort Hinweise auf die weiterführenden Perl-Manuals.
Eine Alternative wäre, heute abend zum Perl-Mongers-Treffen zu kommen. :-)
Dann hätten wir zwar ein überdickes Programm, aber für ein paar Garbage-Collection-Experimente ist immer Zeit.
GreetinX Steffen
lug-dd@schlittermann.de writes:
Also, wenn ich nach
$a->b($b)
ein undef $b mache, existiert es dennoch als Teil von $a.
Ja. (Vorausgesetzt, Du weist es in der Funktion b() tatsächlich irgendeiner Variablen o.ä. zu, klar. Aber davon gehen wir ja alle aus.)
Mache ich ja, indem ich es im $self des Objektes referenziere.
Genau das soll der Garbage Collector eigentlich übernehmen, dazu ist er ja da. Das Zerstören von $a sollte reichen. Sonst wäre es C-like und für Perl-Geschmack viel zu mühselig.
Ich werde wohl selber bissel experimentieren müssen. Bisher hab ich alles noch vermurkst.
Eine Alternative wäre, heute abend zum Perl-Mongers-Treffen zu kommen. :-)
Wenn ich dazu mal Zeit hätte ... Vielleciht wenn die Kinder mal groß sind, das Haus fertig ist und ich keinen Job mehr habe ;-)
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
Eine Alternative wäre, heute abend zum Perl-Mongers-Treffen zu kommen. :-)
Wenn ich dazu mal Zeit hätte ... Vielleciht wenn die Kinder mal groß sind, das Haus fertig ist und ich keinen Job mehr habe ;-)
Da sehe ich doch noch Reserven. Sollte nicht jeder vier große Hobbies haben? Ich zähle bei Dir nur drei. :-)
He, nur Spaß.
GreetinX Steffen
lug-dd@schlittermann.de writes:
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
Eine Alternative wäre, heute abend zum Perl-Mongers-Treffen zu kommen. :-)
Wenn ich dazu mal Zeit hätte ... Vielleciht wenn die Kinder mal
groß
sind, das Haus fertig ist und ich keinen Job mehr habe ;-)
Da sehe ich doch noch Reserven. Sollte nicht jeder vier große Hobbies haben? Ich zähle bei Dir nur drei. :-)
Naja, meine tolle Frau wollte ich hier nicht so rumtragen .....
Mit freundlichen Grüßen
Jens Puruckherr
At 12:57 13.11.2003, you wrote:
Da sehe ich doch noch Reserven. Sollte nicht jeder vier große Hobbies haben? Ich zähle bei Dir nur drei. :-)
Wo ist die Quelle der Aussage zu den (großen!) 4 Hobbies? Habe manchmal Erklärungsnotstand @home ;-)
Beste Grüße, Uwe.
Uwe Beger Uwe.Beger@labotest.com writes:
At 12:57 13.11.2003, you wrote:
Da sehe ich doch noch Reserven. Sollte nicht jeder vier große Hobbies haben? Ich zähle bei Dir nur drei. :-)
Wo ist die Quelle der Aussage zu den (großen!) 4 Hobbies? Habe manchmal Erklärungsnotstand @home ;-)
Ein richtig gutes Rhetorik-Argument entbehrt jeglicher Grundlage. So kann es nicht widerlegt werden.
"Don't try this at home."
:-)
GreetinX Steffen
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Jens Puruckherr -
Steffen Schwigon -
Torsten Werner -
Uwe Beger