[linux-l] Debian-Mirror der belug...

[Steffen Dettmer]

* Jan Krueger wrote on Mon, Oct 06, 2003 at 19:55 +0200:
> On Monday 06 October 2003 09:57, Steffen Dettmer wrote:
> > * Jan Krueger wrote on Sun, Oct 05, 2003 at 06:17 +0200:
> > > nee, nicht wirklich, ähm, vielleicht etwas anderes als Java verwenden.
> >
> > Ahh, ich wußte doch, da war was :)
> 
> Da gibts doch was, fällt mir gerade noch ein.
> Was viele machen, und wofür die Sprache ja wie geschaffen zu sein scheint, 
> ist: Objekt kreiren, benutzen, vergessen. Wenn diese "Convinience" in einer 
> hinreichend komplexen Server-Anwendung ordentlich ausgebeuted wird, hat die 
> GC ordentlich zu tun. 

Nee, die langweilt sich in dem Teil so ziemlich (springt alle
paar Minuten oder gar Stunden mal an!).

> Ständig neue Objekte, welche gleich wieder weggeworfen werden.
> Wenn man so in C vorgehen würde, wäre es auch langsam:
> alloc(klein wenig Speicher), free(), alloc(Klein wenig
> Speicher), free() usw ... Zum Glück gibts ja Objekt-"Pooling",
> also man richtet einen "Pool" an Objekten ein und benutzt die
> Objekte in diesem Pool immer wieder. 

Na ja, bis auf String und sowas passiert das ja. Um ein sauberes
und dennoch flinkes Multi-threading zu haben, werden allerdings
öfter mal Objekte kopiert (meist Hashmaps), weil die
Orginalobjekte nur ganz kurz gelockt werden dürfen. Aber das sind
insgesammt nur ein paar KB Nutzdaten.

Und in C++ ist sowas verdammt schnell - selbst mit locking. Aber
performance ist auch nicht mein Problem. Die Stabilität ist es.

> Also in C: alloc(ausreichend viel Speicher), Speicher aufteilen
> und künftig pointer rumschubsen, und irgendwann am ende ein
> free.

Verletzt meist Geheimnis- und/oder Lokalitätsprinzip. Oft ist es
gut, die Instanzen einfach auf den Stack zu schmeißen - ist meist
auch sehr schnell! Nee, Speicherallokation zu optimieren, lohnt
sich IHMO so gut wie nie, soll heißen, wenn man nicht gerade
embedded oder Treiber bastelt, lieber lassen und defensiv
programmieren - meist sind Qualitätsprobleme schlimmer, als
Performanceprobleme, find ich.

> > Macht denn nicht die VM das GC schon? Sollte dann nicht so viel
> > helfen, oder?

> Zuersteinmal ist die VM nur eine VM, also eine Maschine, dumm, dümmer als 
> Stroh (Stroh hat ja noch genetische Intelligenz, oder? :)

Die Java-VM? Die kann doch verdammt viel? So viel, daß man sie
z.B. nicht im Embedded-Bereich verwenden kann...

> Diese VM hat nich so wirklich Ahnung von Objekten und wurde von
> SUN in Form des Java Prozessors teuer in Silizium gegossen und
> vielleicht 20 mal als Thin-Client verkauft. Diese VM
> interpretiert ByteCode und der kann machen was er will, halt im
> Rahmen der VM Gegebenheiten.  

Ich hab mir nur mal früher ganz bißchen Java-Byte-Code
angeschaut. Da ist doch sogar reflection-basis-Kram drin und
alles? Für mich heißt dumm sowas wie Standard-CPU Befehlssatz...

> Dann kommt Java hinzu und Plötzlich bekommt alles eine
> Bedeutung, Objekte machen sinn und die GC plötzlich auch. Die
> GC läuft ja innerhalb der VM.

Ja sicher, vermutlich funktioniert es deshalb auch nicht (weil
der GC nicht wirklich exklusiv arbeiten kann), aber er nutzt
sicherlich viel Funktionen der VM.

> Wenn man sich andere Objektorientierte Sprachen anschaut und
> dabei C++ mal aus den Augen verliert, dann fällt auf, daß recht
> viele davon eine GC mitbringen, ohne VM, und die GC kann
> äußerst effektiv sein. 

Ja, schon. Gibt ja auch GC's für C++. Find ich aber gar nicht so
wichtig. Hat man ein schönes Design und programmiert defensiv,
dann braucht man GC eigentlich selten bis nicht. Es ist klar, wem
eine Instanz gehört, also kann man es hier auch ggf. entsorgen.
Und dabei dann deterministisch Destruktoren verwenden - ist auch
was wert! Ich denke, OO meint auch, daß it der Konstruktion ne
Resource allokiert und mit Destruktion freigegeben wird. Geht ja
Java z.B. nicht mehr wirklich schön. Aber für ne GUI, wo's egal
ist, ist das natürlich prima.

> > Vermutlich sind Themen wie GC und sowas einfach nicht in der
> > Serverwelt verwendbar, weil jedes *fast* perfektes System
> > totsicher ein Problem hat, wenn es Millionenfach verwendet
> > wird (z.B. ein lange laufender Server).
> 
> Ganz und gar nicht. Es gibt im Netz sehr interessante Beispiele für die 
> Anwendung von Objektorientierten sprachen mit GC in hochkomplexen, 
> performance-kritischen (Antwortzeit kleiner soundsoviel Sekunden), 
> hochverfügbaren, verteilten Anwendungen, halt nicht unbedingt
> in Java oder C++ ;)

mmm... In C/C++ findet man sicherlich ne Menge. Java weiß ich
nicht. Ich glaub, ich würde es nicht nochmal nehmen, einfach,
weil man im Falle des Falles keine Chance hat...

> Schon interessant wie vielseitig das Subject "Debian-Mirror der
> belug..." interpretiert werden kann ;)

Ist der nicht in Java implementiert? ;)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.