[Vienna-pm] Vars in sub max {..}

peter pilsl pilsl at goldfisch.at
Fri Feb 3 05:02:56 PST 2006


Carl A. Schreiber wrote:
>   }
> Angenommen, dieses max() ist Teil eines Moduls (use ..),
> wann und wie oft wird $x angelegt, also ihr Speicherplatz reserviert.. bzw, 
> wann wird dieser Speicherplatz wieder freigegeben?
>   ( einmal beim laden des Moduls ),
>   einmal bei der ersten Ausführung
>   jedesmal, wenn max aufgerufen wird
>   ( .. ?)
> ?


#!/usr/bin/perl -w

foreach (1..100) {a($_)};
sub a {
     my $x = shift;
     print \$x,"\n";
}


Man sieht, dass der Speicherplatz bei jedem Aufruf ein anderer ist, der
sich aber auch mal wiederholen kann.

Die genaue Funktion der Speicherfreigabe ist nicht nur Aufgabe von perl
und keinesfalls deterministisch.

Was fix ist:
bei jedem Aufruf der sub wird $x neu erzeugt. An welchem Speicherplatz
ist nach aussen zufällig.  Bei Ende der sub wird $x wieder freigegeben
und damit im perl-internen sinn auch zerstört.
Wann der Speicherplatz jetzt tatsächlich freigegeben wird im Sinne von :
jetzt dürfen andere threads/applikationen darauf zugreifen, ist viel
schwieriger. Da gibts mal eine perl-interne "garbage-collection" aber
auch OS-abhängige Prozesse. (bzw. auch abhängig von den verwendeten libs
auf dem OS)

Im grossen und ganzen kann man darauf vertrauen, dass perl intern die
garbage-collection gut macht und den speicher so verwaltet, dass alter
speicher freigegeben wird, wenn neuer benötigt wird und dass auch OS wie
linux das gut machen.

Aber die Aufgabe ist extremst komplex und es gibt speicherstrukturen,
die perl überfordern und es gibt immer wieder bugs in der
garbage-collection von perl und dann gibt es natürlich prinzipielle
probleme wie zirkuläre referenzen  $a->{x}-{y}=[1,2,\$a,4,5];  die von
einem counter-basierten garbage-collector wie perl gar nicht aufgelöst
werden *können*.

Das Stichwort für weitere Vertiefung ins Thema ist auf jeden Fall
"garbage collection" und "memory managment"

der perl-garbage collector ist auf jeden fall kein highlight in der welt
der prorammiersprachen :

"If you're like most people, you've never seen a good garbage collector,
because, while all of the commercial Lisp and Smalltalk systems had high
quality GC, just about all of the open source garbage collectors are
junk (e.g., Perl, Python, and Emacs.) Perl's GC is an especially bad
joke: if you have circular references, the objects won't get collected
until the program exits! Give me a break! (Update: I'm told that
Python's so-called GC is just as bad, since it is also merely
reference-counting instead of a real GC.)"   von jamie zawinsky

aber der in 5.8 ist viel stabiler und intelligenter als der in 5.6 und
von perl6 erwarten wir uns hier einen Quantensprung.

Bisher komme ich selten umhin, mir eigene GarbageCollectoren für
grössere Projekte zu basteln (kämpfe aber dennoch seit März mit einem
unentdeckten mem-leak in einer mod_perl-application :)

lgp




-- 
mag. peter pilsl
goldfisch.at
IT- & dataconsulting
tel: +43 650 3574035
tel: +43 1 8900602
fax: +43 1 8900602 15
pilsl at goldfisch.at



More information about the Vienna-pm mailing list