[linux-l] ein biscchen offtopic: php Frage

[Guntram Trebs]

On Mon, 25 Nov 2002, Rainer Flicker wrote:

> Date: Mon, 25 Nov 2002 22:49:23 +0100
> From: Rainer Flicker <r.flicker at nexgo.de>
> Reply-To: linux-l at mlists.in-berlin.de
> To: linux-l at mlists.in-berlin.de
> Subject: Re: [linux-l] ein biscchen offtopic: php Frage
>
> Hallo,
>
> > Ja, könnte man denken, stimmts? Ist auch nicht einfach zu
> > untersuchen, was da nu warum rumliegen bleibt und überhaupt...
> > Jedenfalls hat auch JDK-1.4 Bugs, ist ja auch klar.
> Ok, der garbage collector ist nicht so gut wie ein Programmierer,
> der weiß, wann ein Objekt nicht mehr benötigt wird. Aber trotzdem
> sollten keine Speicherlecks durch den gc entstehen. Und von Bugs
> in Java 1.4.1 bin ich bisher einigermaßen verschont beblieben, hab
> aber auch keine Java-Programme tagelang laufen.

Ein Garbage-Collector ist immer ein Kompromiß. Je besser er rausfinden
kann, welche Objekte noch benötigt werden und welche nicht, desto mehr
Rechenzeit und Speicher braucht er.

Ich weiß jetzt nicht genau, ob die Art der Garbage-Collection für die java
virtual machine vorgeschrieben ist, kann mir aber vorstellen, daß nur
Minimalanforderungen dafür festgelegt sind. Dann wäre es durchaus möglich,
daß einige virtual machines Speicherlöcher erzeugen und andere nicht bei
bestimmten Code.

Als Programmiere sollte man davon ausgehen, daß die virtual machine nur
Referenzzähler benutzt, sprich mitzählt, wieviele "Stellen" es gibt, von
denen aus noch auf ein Objekt zugegriffen wird.

Wenn ich also zwei Objekte habe, die gegenseitig auf sich selbst
verweisen, dann werden sie von einem "schlechten, aber performanten"
Garbage-Collector nicht entfernt. Falls man solche Strukturen braucht, muß
man die entsprechenden Variablen dann mit Null belegen, bevor man die
Objekte für immer vergißt. Das Problem dabei ist, daß sich solche
Strukturen manchmal sehr verstecken und man es deshalb nicht mitbekommt.

Außerdem gibt es ja noch Strukturen, wo garbage collectoren keine Chance
haben. Eine unendlich lange Liste, wo nur an einem Ende was dazugepackt
wird, aber nur die neuesten Elemnte verwendet werden, besteht zum größten
Teil aus garbage, aber kein noch so guter Garbage-Collector kann Elemente
dieser Liste entfernen, denn sie sind ja noch verlinkt und er weiß ja
ncht, ob nicht doch nchmal irgendwann eins der ältesten Elemente verwendet
wird.

Ein ähnliches Beispiel wäre ein Stack, auf dem man arbeitet und immer was
raufpack und wieder was runterholt, ohne zu merken, daß man tendenziell
viel mehr raufpackt, als man abholt.

Möglicherweise hat man auch einen eigenen Thread, der sich um das Abholen
kümmmert, der wird aber nie ausgeführt, weil er eine zu niedrige Priorität
hat.

Wichtig ist, daß man sich darüber von vornherein Gedanken macht und
kritische Strukturen vermeidet, bzw. zumindest innerlich begründet, warum
diese Strukturen nicht kritisch sind und dann nochmal Tests fährt, ob sich
das Programm tatsächlich wie vorausgeplant verhält.

> > Na ja, ob nu MVC oder MFC's DocumentView; ist im Prinzip das gleiche
> > (Information und Repräsentation trennen). Aber Swing ist sauber
> > und verwendet überall Polymorhpie, für jede noch so billige
> > Komponente. Natürlich super zu programmieren, schön, sauber,
> > logisch und schlüssig. MFC mit der furchtbaren Macro-Bastelei,
> > der Unsauberkeiten und ständigen Ausnahmen ist dadruch natürlich
> > schneller (ist ja klar, wenn man als Programmierer schon diesen
> > Mist verdrahtet, muß es die Laufzeit nicht machen). Ich war echt
> > überrascht, wie einfach man z.B. ne Progressbar in eine JTable
> > kriegt, absolut wie's sein muß, nämlich im Prinzip mit drei
> > Zeilen, das macht Spaß.
> Java Swing ist auch ein tolles Beispiel für design pattern. Das
> gesamte swing beseht fast nur aus pattern. Dazu gibt es auch eine
> interessante Präsentation von Gamma (einer der GoF).

Das was ich da bis jetzt probiert habe, gefällt mir auch sehr sehr sehr
gut. Dummerweise stehen wir jetzt vor dem Problem, ein Programm auf
FreeBSD laufen zu lassen, so daß ich auf ein paar Sachen wieder verzichten
muß. Die FreeBSD-Implementierung der jvm hinkt leider ein wenig hinterher
:-(

> > Mmmm, dachte, daß die meisten libc Funktionen threadsafe seien,
> > schließlich wird doch interes static kaum noch verwendet? Und
> > Funktionen, die auf lokalen Variablen arbeiten, sind ja
> > threadsafe, und der Kernel sollte es auch sein :)
> In den UNIX-Standards (UNIX98, SUS2, ...)sind nur wenige Funktionen
> als threadsafe definiert. Was die glibc macht ist was anderes. Wenn
> man darauf vertraut, sieht es schlecht mit der Portabilität aus.
> Dann kann man race conditions studieren. :-)
>
> > Was ist "async-safe"?
> Für threadsafe reicht es schon sicherzustellen, dass eine Funktion
> nur einmal gleichzeitig aufgerufen wird. Eine async-safe kann mehr-
> mals gleichzeitig aufgerufen werden, ohne dass die Ausführung blockiert
> wird.

Hmm. Habe ich das jetzt richtig verstanden?:

Wenn man Objekte verwendet, die Thread-Safe sind, entstehen zwar keine
logischen Fehler(*), aber die Abarbeitung kann blockiert sein, da ein
anderer Thread gerade das Objekt bzw. den für mich interessanten Teil
blockiert, so daß ich - unabhängig von meiner Priorität - möglicherweise
gar nicht mehr aus der Methode rauskomme, falls ich gleichzeitig den
anderen Thread auch wiederum blockiere. (Das sind wohl die
race-conditions)
Und bei async-safe wird mir zugesichert, daß mich zumindest niemand
blockieren kann.

(*) mit logischen Fehlern meinte ich Seiteneffekte etc. nicht die
zeitliche Blockade



Guntram