Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.02.2001 - 

Compiler-Entwicklung steckt noch in den Kinderschuhen

Java hat viel Spielraum für Verbesserungen

23.02.2001
MÜNCHEN (CW) - Einer gängigen Einschätzung zufolge sind Java-Anwendungen langsam, weil der Programmcode über den Umweg einer virtuellen Maschine zur Laufzeit kompiliert wird. Doch neueste Benchmarks belegen, dass Java-Code aus IBM-Compilern nicht mehr wesentlich langsamer ist als C++-Code.

Auf dem Gebiet der Optimierung und bei den Just-in-Time-(JIT-)Compilern wurden in den letzten Jahren große Fortschritte gemacht. Vor allem Big Blue hat hier viel Grundlagenforschung betrieben und kann den schnellsten Java-Compiler der Branche vorweisen. Einer Studie von Technology Decision Matrix zufolge ist der IBM-Code mittlerweile nur mehr unwesentlich langsamer als C++-Code aus dem Intel-Compiler, und sogar geringfügig schneller als Microsofts Visual C++.

Um die in den Anfangsjahren langsamen Java-Programme zu beschleunigen, haben die Hersteller unterschiedliche Techniken ersonnen. Ein vielfach beschrittener Weg ist die Kompilierung von Bytecode in nativen Code. Für Windows existieren dafür beispielweise die Produkte "Jet" von Excelsior, "Visualcafe" von Webgain oder "Towerj". Letzteres ist wie "GCJ" Open Source und auch für Linux und Unix erhältlich.

Auf den ersten Blick scheint die Kompilierung in nativen Code große Vorteile zu bieten. Doch gleichzeitig werden dadurch einige typische Stärken von Java aufgegeben. Nativer Code ist an eine bestimmte Zielplattform gebunden und benötigt deutlich mehr Speicherplatz als Java-Code. Vor allem aber werden dabei die von Java bekannten Sicherheitsmechanismen ausgehebelt.

Eine bessere Lösung stellen JIT-Compiler dar, da sie die Vorteile von nativem Code mit denen von Java kombinieren. Anstatt eine ganze Anwendung zu kompilieren, lädt ein JIT-Compiler den Byte-Code und kompiliert ihn zur Laufzeit. JIT-Compiler haben dennoch gewisse Nachteile. So produzieren sie einen gewissen Overhead und können Fehler enthalten, die sich auf Java-Programme auswirken. Daneben benötigt jede Plattform einen eigenen JIT-Compiler, was jeweils Konfigurationsaufwand mit sich bringt.

Mit Hotspot hat Sun einen Beitrag zur Leistungssteigerung von Java-Anwendungen eingebracht, der einen Kompromiss zwischen JIT-Kompilierung und JVM-(Java Virtual Machine-)Ausführung bietet. Werden Teile eines Programmcodes nur einmal ausgeführt, ist der Geschwindigkeitsgewinn durch Kompilierung geringer als die Zeit, die während der Kompilierung vergeht, was zu einer geringeren Gesamt-Performance führt. Hotspot führt deshalb zunächst den gesamten Code in der JVM aus und analysiert dabei, welche Passagen von einer Kompilierung profitieren. Die übrigen Abschnitte werden im Bytecode beibehalten.

Im Allgemeinen ist es schwierig, die generelle Geschwindigkeit von JVMs zu ermitteln, da Java auf sehr vielen Plattformen läuft und die heutigen Benchmarks noch unausgereift sind. IBMs virtuelle Maschinen gelten aber auf den eigenen und der Windows- Plattform als die schnellsten. Suns Hotspot ist neben anderen JITs und nativen Compilern ebenfalls als sehr schnell einzustufen.

Interessant ist eine Entwicklung von Gemstone Systems. Das Unternehmen, das bisher für Technologien im Bereich Objektdatenbanken bekannt war, hat mit "Gemstone/J" eine Hochleistungs-JVM herausgebracht. Statt des üblichen Ansatzes mit einer JVM pro Computer verteilt und koordiniert Gemstone/J viele verschiedene JVMs. Dadurch ergeben sich einige Vorteile wie kürzere Pausen bei der Garbage Collection und geringere Speicherbelegung. Außerdem können verschiedene JVMs jeweils für unterschiedliche Anwendungen optimiert werden.

Was Java in jedem Fall für eine angemessene Arbeitsgeschwindigkeit voraussetzt, ist eine üppige Ausstattung mit Arbeitsspeicher. In der Regel belegen Java-Programme etwa den vierfachen Speicher wie C- und C++-Anwendungen und das Zweifache im Vergleich mit Skripten in Perl, Python, Rexx oder Tcl. Ein Java-Entwickler benötigt auf seinem Rechner also mindestens 128 MB RAM, wobei die idealen Voraussetzungen erst mit 512 MB und mehr erfüllt sind.

Sun ist stets davon ausgegangen, dass die Hersteller von Betriebssystemen sich um die Entwicklung von virtuellen Maschinen für Java bemühen. Diese Rechnung ist bisher nicht aufgegangen, einzig IBM hat hier über seine eigenen Produkte hinaus Leistungen eingebracht. Microsoft, der größte Betriebssystem-Hersteller, ist gerade dabei, sich weitgehend aus dem Java-Geschäft zurückzuziehen, und versucht mit .NET, eine Gegenstrategie zu lancieren. Der einst populärste Browser "Navigator" von Netscape schließlich, der für viele Anwender die Standardlaufzeitumgebung für Java-Applets war, fiel seit jeher durch seine bescheidene JVM-Implementierung unangenehm auf.

Die Compiler-Entwicklung steckt bei Java noch in den Kinderschuhen. Erfahrungsgemäß ist die Forschung und Entwicklung von effizienten Compilern eine schwierige Aufgabe, die Jahre dauert, wie an Beispielen wie C++ oder Fortran zu sehen ist. Java ist aber mit seinen gut fünf Jahren auch noch sehr jung, daher dürften die nächsten fünf Jahre noch einige spürbare Verbesserungen im Bereich Leistung, Zuverlässigkeit und Fehlerbereinigung bringen.

Abb: Wofür Java-Virtual-Machines Zeit benötigen

Bei grafischen Anwendungen am Client fressen vor allem die nativen Bibliotheken die Ressourcen, am Server braucht die Bytecode-Ausführung die meiste Zeit. (Quelle: Sun)