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

[Jan Krueger]

On Monday 06 October 2003 09:57, Steffen Dettmer wrote:
> * Jan Krueger wrote on Sun, Oct 05, 2003 at 06:17 +0200:
> > On Saturday 04 October 2003 22:41, Steffen Dettmer wrote:
> > > Ich war von dem Speichermanagement von Java (bis einschließlich
> > > 1.4) nicht zufrieden.
>
>  [...]
>
> > > sein?" nichts gehört... Gibt es da einen Trick?
> >
> > 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. 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. Die folge ist, daß 
die GC nix zu tun hat, das Objekt-Gerüst immer schon da ist und man also nur 
die inneren Werte entsprechend den neuen Gegebenheiten anpassen muß. Klingt 
schneller, oder?
Also in C: alloc(ausreichend viel Speicher), Speicher aufteilen und künftig 
pointer rumschubsen, und irgendwann am ende ein free.

> > Was eventuell eine alternative sein könnte, wäre eine andere
> > Sprache als Java zu nehmen deren Compiler jedoch Bytecode für
> > die Java Virtual Machine erzeugt. Quasi C für JVM oder so.
>
> 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? :)
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.
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.

> > Oh, damit werde ich zum differenzieren zwischen Byte-Code und
> > Java gezwungen. Also Orion ist vielleicht gar kein Java?
>
> Der Bytecode ist aber recht Java-optimiert, oder? Weiß nicht, ob
> da (von Syntax, Typen etc) viel Mehrwert erreicht werden kann.
> Nicht umsonst hat ja jede neue Javaversion ne neue VM...
Der ByteCode (Maschinencode für die VM) ist optimiert für einfache 
Interpretation durch einen Interpreter. Die neuen VMs sind ja nur 
unterschiedliche Implementierungen der selben (im Sinne der Spezifikation) 
Maschine.

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. Ich habe manchmal den 
eindruck, daß SUN sich mit dem Java-Hype selbst überrumpelt hat und, um 
Zeitgerecht Features zu liefern, so manches andere aus den Augen verloren 
hat. Java hat sich im vergleich zu anderen Sprachen wirklich sehr schnell 
entwickelt, insbesondere der ganze Bloat den java mitliefert. Vielleicht war 
das etwas zu schnell für die entwicklungsfähigkeiten von Sun.

> > Wenn Sun die VM ein wenig aus dem Java-Nebel herauslöst, viele
> > Sprachen erzeugen VM Bytecode, vielleicht gibt es dann ja mehr
> > wirklich tolle Lösungen?
>
> Java ist schon toll - aber mehr auch nicht :-)
:)

> 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++ ;)
Teilweise Dinge, welche mit C und dergleichen, schwierig zu realisieren wären, 
zb. wegen des notwendigen compilierens, worauf man bei manchen oo-sprachen ja 
verzichten darf, änderungen zur laufzeit möglich werden und ähnliches.

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

Gruß
Jan