🚀 go-pugleaf

Elcaro Nosille wrote:

>> Stimmt, aber eine Pentium-CPU führt ja auch nicht Maschinencode aus, 
>> sondern interpretiert ist. Denn die Stufe darunter ist der Microcode ;-) 
>> Sonst könnte man auch auch keine (Intel-)CPUs via BIOS-Updates 
>> pat(s)chen ...
> 
> Man kann auch in einen Zwischencode kompilieren wie es Java
> macht und wie es die meisten sog. "Interpreter" intern tun.

Sorry, ich kann dem nicht mehr länger zulesen ...

Java wird von HotSpot, sofern nötig (hier greift die 20-80-Regel: Nur 20%
des Code sind überhaupt für die Performance eines Programms relevant), in
Maschinencode kompiliert. Läuft es auf einem AMD64, kommen hier
AMD64-spezifische Instruktionen zum Einsatz. Läuft es auf einem P4, kommen
P4-spezifische Instruktionen zum Einsatz. Der Vorteil von HotSpot,
gegenüber jedem statischen Compiler, ist, dass HotSpot die Kiste, auf die
es compilieren soll, ganz genau kennt.

HotSpot kann in drei Modi laufen: Interpreted (das ist das, was wir von Java
1.1 ohne JIT kennen), Mixed (ein Teil wird compiliert, bei einem Teil
belässt man es dabei, den von javac erzeugten Bytecode zu interpretieren,
das sind die oben genannten 80%), und Compiled (alles wird compiliert,
abgesehen von der Code-Qualität ungefähr das, was wir von Java 1.1 mit JIT
kennen).

"Interpreted" macht keinen Sinn, zu 1.3 musste das noch da sein, weil man
anders nicht debuggen konnte. Das ist inzwischen korrigiert. Einige
argumentieren noch für diesen Modus, wenn man profilen will. Aber Profiling
ohne HotSpot mit einzubeziehen, ist Schwachsinn, denn wenn man schlauer als
HotSpot sein will, geht der Schuss nach hinten los.

"Compiled" mag auf den ersten Blick Sinn machen, tut es aber nur begrenzt.
Einige Anwendungen könnten davon tatsächlich profitieren, aber da HotSpot
ein hochoptimierender Compiler ist und in Java ständig zur Laufzeit Klassen
nachgeladen werden, geht dieser Schuss meist nach hinten los -- schnell
Klassen laden zu können ist wichtig, das machen wir in Java nämlich
ständig, und HotSpot nimmt sich schon etwas Zeit bei der Compilierung. Das
Laden von Klassen zu verlangsamen ist, vor allem in Anbetracht der
20-80-Regel, kontraproduktiv.

"Mixed": HotSpot beobachtet das Laufzeitverhalten des Programms und
versucht, die 20%, die für die Performance relevant sind, zu ermitteln. Hat
die JVM einen solchen "Hot Spot" identifiziert, wird darauf ein hochopti-
mierender Compiler angesetzt. Wie gesagt, dieser Compiler kennt die
Gegebenheiten dann ganz genau, und nutzt, was er nutzen kann. Die Sache
geht ziemlich weit, besonders auch, wenn man bedenkt, dass die Gegebenhei-
ten sich jederzeit ändern können, wenn Klassen nachgeladen werden: So kann
z.B. erstmal ein Inlining einer Methode als sinnvoll erscheinen, danach ein
ein Loop-Unrolling. HotSpot tut das. Kommt später eine Klasse hinzu, die
das vorherige Inlining verunmöglicht und man dort einen Methoden-Aufruf
stehen haben muss, macht HotSpot diese Optimierung rückgängig.

Ich habe jetzt ständig "HotSpot" geschrieben, aber jede JVM, die diese
Bezeichnung verdient, macht sowas heutzutage, "HotSpot" heisst es einfach
dann, wenn es von Sun oder (neuerdings) OpenJDK.org kommt.

Hört bitte auf, Perl oder PHP zu diesem Thema mit Java zu vergleichen ...
dass Perl oder PHP, vor allem in Relation zu den Entwicklungskosten, häufig
effizienter erscheinen, und auch sind, ist unbestritten. Aber Java spielt
da in einer anderen Liga.

Dass viele Java-Programme langsam erscheinen, liegt zu einem grossen Teil
daran, dass die Programmierer ständig die JVM verarschen wollen, um dieser
Langsamkeit, die Java nachgesagt wird, entgegen zu wirken. Zudem wollen sie
nicht begreifen, dass man den GC am besten einfach seinen Job machen lässt,
der funktioniert nämlich wesentlich komplexer, als einige es wahrhaben
wollen. Kurz: Vor lauter sich Gedanken um die Performance zu machen,
verwirrt man ein sehr ausgeklügeltes System derart, dass dieser Schuss
gründlich nach hinten los geht: Dieses ausgeklügelte System weiss nämlich
plötzlich nicht mehr, was es mit diesem "ausgeklügelten und auf Performance
optimierten Java-Code^WChaos" überhaupt anstellen soll ...

Was ich wohl zur Aussage, Java sei einfach, sagen könnte ... ich überlasse
es dem geneigten Leser, sich das auszumalen.

Dass Java ein Speicherfresser ist, ist Tatsache, wohlbekannt und unbestrit-
ten.

Gruss,
   Raffi

-- 
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is *nothing* like Shakespeare!

herzog@raffael.ch · PGP Key 5D1FF5F4 · http://www.raffael.ch/