„Bytecode“ – Versionsunterschied

Bytecode ist in der Informatik die Bezeichnung für eine Sammlung von Befehlen, also die Maschinensprache für eine virtuelle Maschine. Bytecode bezeichnet sowohl die Vorschrift wie der Quellcode von Programmen in diesen Objektcode zu kodieren ist, als auch die Ergebnisse dieser Kodierung, also die ausführbaren Programme. Bytecode ist im Gegensatz zu Quelltexten oder Skripten nicht „menschenlesbar“, Programmanweisungen und Werte sind wie in Maschinencode als Bytes codiert. Maschinencode wird jedoch direkt von einem (Hardware) Prozessor ausgeführt, Bytecode dagegen betont, dass das Programm zunächst von einem speziellen anderen Programm „interpretiert“, in Maschinencode übersetzt wird. Ein Bytecode kann jedoch von passenden Hardware-Prozessoren direkt ausgeführt werden, und Maschinencode wird meist, sozusagen als Bytecode, auf Software-Prozessoren entwickelt.

Bei Kompilierung eines Quelltextes mancher Programmiersprachen oder Umgebungen – wie beispielsweise Java – wird nicht direkt Maschinencode, sondern ein Zwischencode, der Bytecode, erstellt. Dieser Code ist in der Regel unabhängig von realer Hardware. Er entsteht als Resultat einer semantischen Analyse des Quelltexts und ist im Vergleich zu diesem deutlich kompakter und zumeist wesentlich effizienter interpretierbar als der originale Quelltext.

Technische Details

Die virtuelle Maschine – im Fall von Java die Java Virtual Machine (JVM) – führt dann dieses Zwischenergebnis aus, indem sie zur Laufzeit den Bytecode entweder in Maschinensprache für den jeweiligen Prozessor übersetzt (Just-in-time-Kompilierung) oder entsprechende Maschinencode-Routinen ausführt (Interpreter). Dabei muss die virtuelle Maschine für jede Rechnerplattform, auf der das Kompilat ausgeführt werden soll, vorhanden sein.

Java ist nur eines der prominenteren Beispiele für eine Bytecode-basierte Programmiersprache. Andere Sprachen, die Bytecodes verwenden, sind etwa P-Code, Lua, die .Net-Framework-Sprachen C#, F# und Visual Basic, Python, Ruby, Perl, PHP, Prolog, Limbo, Gambas sowie Tcl. Während bei Java, Python und .NET der Bytecode als „Kompilat“ gespeichert und dann unabhängig vom Quellcode ausgeführt wird, wird bei den Skriptsprachen Perl (bis Version 5) und Tcl beim Programmstart der Quellcode in Bytecode übersetzt und nur im Arbeitsspeicher vorgehalten.

Die Verwendung von Bytecode macht es möglich, dieselbe virtuelle Maschine für mehrere Sprachen zu verwenden, beispielsweise die JVM für Java, Scala, Groovy und viele andere. Der Aufwand, nur einen Bytecode-Compiler für eine höhere Programmiersprache zu entwickeln, ist dann deutlich reduziert. Dagegen wäre der Aufwand, wenn ein Compiler eine direkte Übersetzung in Maschinencode für mehrere Betriebssysteme und Architekturen bereitstellen soll, sehr viel höher. Ein Bytecode kann auch unabhängig von einer speziellen Sprache für einen bestimmten Einsatzzweck entwickelt worden sein, zum Beispiel WebAssembly.

Die Ausführung von Bytecode durch das Programm, das die virtuelle Maschine repräsentiert, geht auf Kosten von dessen Startzeit, welche im Allgemeinen aber eher nur messbar als wahrnehmbar beeinträchtigt wird. Spezielle Just-in-time-Compiler (JIT-Compiler) übersetzen Bytecode-Stücke einmal während der Programmausführung in entsprechende Maschinencodestücke und führen diese dann aus. Dadurch lassen sich die Ausführungszeiten, jedoch nicht die Startzeiten, oft in den Bereich von vorübersetztem Maschinencode reduzieren.

Hintergründe

Viele interpretierte Sprachen verwenden auch intern Bytecode. Das bedeutet, dass der Bytecode an sich unsichtbar für den Programmierer und Endbenutzer gehalten wird und automatisch als Zwischenschritt der Interpretation des Programmes erzeugt wird. Beispiele für aktuelle Sprachen, die diese Technik verwenden, sind: Perl, PHP, Prolog, Tcl und Python. In Python wird der Bytecode nach dem ersten Parsen in .pyc-Dateien (welche den Bytecode enthalten) abgelegt; das Vorgehen ähnelt damit prinzipiell dem bei Java. Dieser Schritt ist jedoch optional.

Auch dieses Verfahren ist sehr alt: Bereits für Lisp wurde in den 1960er Jahren Bytecompiling eingesetzt: Die 256 atomaren Funktionen wurden in einem Byte kodiert. Frühe BASIC-Versionen der 1970er und 1980er Jahre verwendeten anstelle der Schlüsselwörter bestimmte Byte-Werte, sogenannte Tokens, um die Ausführung ihrer Programme zu beschleunigen und den Programmtext in einer kompakteren Form abzuspeichern. Der restliche Text – zum Beispiel Variablen, mathematische Ausdrücke und Zeichenketten – wurde jedoch unverändert gespeichert. Bei Ausgabe durch den LIST-Befehl wurden die Tokens wieder in lesbare Schlüsselwörter umgewandelt. Ein bekannter früher Heimcomputer, der Bytecode verwendet, ist der TI 99/4a von Texas Instruments.

Aufgrund des stark begrenzten Speicherplatzes der ersten Homecomputer war es unumgänglich, beispielsweise BASIC-Programme als Bytecode in den RAM zu überführen. Alternativ konnte man nur mit direkt eingegebenen Maschinencode programmieren. Reiner Text wäre sehr schnell an die Speichergrenze gestoßen. Die Platzersparnis von Quelltexten in Bytecodeform war aber auch später noch angesichts langsamer und begrenzter Massenspeicher von Vorteil. Hinzu kommt der große Vorteil, dass Bytecode deutlich schneller ausgeführt werden kann als ein normaler Quelltext. Statt jeden Buchstaben eines Befehls zu vergleichen, um erst mal herauszufinden, um welchen Befehl es sich handelt, muss man nur ein oder wenige Bytes vergleichen, die diesen repräsentieren.

Rückgewinnung von Quelltext aus Kompilaten

Für Programmierer, die an Programmen arbeiten, deren Quellcode nicht offengelegt werden soll, gibt es einen wichtigen Aspekt zu beachten: Bei Programmiersprachen, wie beispielsweise C, die direkt zu Maschinencode kompiliert werden, ist es normalerweise nicht möglich, aus dem Maschinencode den ursprünglichen Quellcode zurückzugewinnen. Dazu müssten mindestens die Algorithmen des verwendeten Compilers bekannt sein. Funktionsbezeichner und Variablennamen können allerdings nur dann ermittelt werden, wenn dem Compilat Daten für einen Debugger hinzugefügt wurden.

Bei Kompilierung zu Bytecode ist dieses sogenannte Dekompilieren hingegen viel einfacher, da dieser sich weniger an der abstrakten Maschinensprache orientiert, sondern meistens deutlich näher an der zugrundeliegenden Programmiersprache liegt. Hierbei kann zwar nicht der exakte Quellcode rekonstruiert werden, allerdings ist es häufig möglich, zumindest äquivalenten Code in der Quellsprache zurückzugewinnen, teilweise mit verblüffenden Ähnlichkeiten. Beispielsweise bei Java und .NET ist dies in den meisten Fällen sehr gut möglich; in Prolog mit WAM-Bytecode ist eine Rückgewinnung immer möglich;

Mithilfe eines sogenannten Obfuskators kann die Nutzbarkeit des durch das Dekompilieren erhaltenen Quelltextes sehr stark eingeschränkt werden. Mitunter werden Befehlsfolgen eingebaut, die in der Quellsprache nicht existieren (beispielsweise Code nach Ende einer Methode), was ein Dekompilieren in die Quellsprache gar nicht mehr möglich macht.

Weblinks

• Bill Venners: Bytecode basics. A first look at the bytecodes of the Java virtual machine (Memento vom 6. März 2016 im Internet Archive) in javaworld.com vom 1. September 1996 (englisch) – Java-Bytecode entschlüsselt