Mehr als nur x86
Typischerweise haben Linux-Distributionen Unterstützung für CPU-Architekturen, die man eher weniger in Laptops und dafür umso mehr in Servern findet. Die Linux-Welt ist weit größer als nur x86 und amd64, daher ist es für Linux-Distributoren von großer Wichtigkeit, auch andere CPU-Familien abdecken und damit Open Source Java überall mit Linux zusammen ausliefern zu können. Einen ersten Schritt machte dabei Sun mit der Veröffentlichung der SPARC-Portierung der Hotspot JVM für Linux und des C++-Interpreters für Hotspot. Der C++-Interpreter diente als Grundlage für Red Hats Portierungsarbeiten.
Red-Hat-Entwickler Gary Benson hatte zuerst mit einer Portierung des C++-Interpreters für Power PC begonnen. Nachdem die Portierung erfolgreich war, wollte er es vermeiden, für weitere von Red Hat unterstützten CPU-Architekturen auch eine separate Portierung mit dem dazugehörigen Assembler-Code zu schreiben und sie später von einander getrennt warten zu müssen. Daher entschied er sich, einen „generischen“ Backend für den Hotspot-C++-Interpreter zu implementieren, der ganz ohne Assembler-Code auskommt. Dieser Backend wurde Zero getauft, als Kurzform von Zero-Assembler.
Der C++-Interpreter in Hotspot setzt Assembler für zwei Dinge ein: Verwaltung von Stack und Aufrufe von nativem Code. Wenn man von Java aus nativen Code aufruft, z.B. eine Funktion aus einer in C geschriebenen Bibliothek, muss die JVM die Parameterübergabe aus der Java-Welt in die native C-Welt so gestalten, dass die C-Funktion die richtigen Parameter in richtiger Reihenfolge und Größe beim Aufruf übergeben bekommt und auch an der richtigen Stelle das Ergebnis des Aufrufs gespeichert wird. In der Praxis heißt das, es gibt für jede CPU-Architektur und jedes Betriebssystem einen Satz an Assembler-Code, der sich um die Übersetzung zwischen Java und dem nativen Application Binary Interface (ABI) kümmert. Da sich ABIs z.B. unter Linux auch gerne ändern, ist das alles aufwendiger, als man sich es wünschen würde.
Das haben sich auch die Entwickler der GNU Compiler Collection (GCC) gedacht. Deshalb benutzt der native Compiler für Java-Anwendungen im GCC-Projekt die libffi-Bibliothek. Libffi erlaubt es, native Funktionsaufrufe mit ihren Parametern und Rückgabewerten zusammen zu basteln, ohne sich in die Tiefen der jeweiligen ABI und Assemblers zu stürzen. Zero setzt daher auf libffi für diese Aufgabe und entledigt sich des Rests von Assembler-Code im Interpreter durch eine Neuimplementierung der Stack-Verwaltung in C++.
Gary hat Zero im Februar auf der FOSDEM Konferenz vorgestellt. In der Zwischenzeit wurde Zero auf Alpha, ARM, Itanium, M68K, MIPS, Power PC und s390-CPU-Architekturen zum Laufen gebracht, und ist z.B. in Debian dafür verantwortlich, dass OpenJDK auch auf diesen Plattformen läuft.
Da Zero nur ein Interpreter ist, läuft OpenJDK damit naturgemäß nicht sehr schnell, bietet aber einen guten Start in eine „richtige“ Portierung von Hotspot JITs. Dem Ansatz aus Zero folgend, bereits existierende Open-Source-Bibliotheken zu benutzten, statt neu zu entwickeln, arbeitet Gary in den letzten Monaten an Shark, einem Backend für Hotspot JIT Compiler, der auf LLVM aufsetzt. LLVM ist ein Compiler-Bau-Framework für Power PC, ARM, x86, AMD64 und weitere CPU-Architekturen.
Seit August ist Zero ein offizielles Projekt innerhalb von OpenJDK. Im gleichen Monat wurde innerhalb von OpenJDK auch ein Projekt für die BSD-Portierung gestartet.
In der nächsten Kolumne gibt es dann mehr dazu und vor allem wollen wir uns mit dem Thema OpenJDK unter Mac OS X beschäftigen.
