DE69533005T2

DE69533005T2 - Bytecodeprogramminterpreter, Verfahren und Anordnung mit Vorprüfung von Datentyprestriktionen

Info

Publication number: DE69533005T2
Application number: DE69533005T
Authority: DE
Inventors: James A. Woodside Gosling
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1994-12-20
Filing date: 1995-12-19
Publication date: 2005-05-04
Anticipated expiration: 2015-12-20
Also published as: US5740441A; DE69523029D1; EP1118940A3; EP0718764A3; US5999731A; JP3868527B2; US7080363B2; US20030135844A1; EP1533696A2; US5748964A; EP0718764A2; DE69533005D1; EP1533696A3; US6477702B1; EP1118940B1; US6247171B1; JPH08234994A; EP1118940A2; EP0718764B1; DE69523029T2

Description

Die Erfindung betrifft ein computerimplementiertes Verfahren, ein Computer-System und ein Computer-Programmprodukt gemäß den Oberbegriffen der Ansprüche 1, 13 bzw. 25.
Folglich betrifft die vorliegende Erfindung im Allgemeinen die Verwendung von Computer-Software auf mehreren Computer-Plattformen, die verschiedene zugrunde liegende Maschinenbefehlsvorräte verwenden, und spezifischer einen effizienten Programminterpreter und ein Verfahren, die Prüfungen der Verwendung von Datentypen und Prüfungen der Verwendung des Operandenstapels effizient handhaben.
Wie im Allgemeinen in 1 dargestellt ist, kann in einem typischen vernetzten Computersystem 100 des Standes der Technik ein erster Computer 102 ein Computer-Programm 103 herunterladen, das in einem zweiten Computer 104 gespeichert ist. In diesem Beispiel wird der erste Anwenderknoten 102 typischerweise ein Anwender-Arbeitsplatzrechner sein, der eine Zentraleinheit 106, eine Anwenderschnittstelle 108, einen Hauptspeicher 110 (z. B. einen Schreib-Lese-Speicher) für die Programmausführung, einen Sekundärspeicher 112 (z. B. eine Festplatte) zum Speichern eines Betriebssystems 113, von Programmen, Dokumenten und anderen Daten, und ein Modem oder eine andere Kommunikationsschnittstelle 114 für die Verbindung mit einem Computer-Netz 120, wie z. B. dem Internet, einem lokalen Netz oder einem Fernnetz, besitzt. Die Computer 102 und 104 werden oft als die "Knoten im Netz" oder die "Netzknoten" bezeichnet.
Der zweite Computer 104 wird oft ein Netz-Server sein, er kann aber ein zweiter Anwender-Arbeitsplatzrechner sein, wobei er typischerweise die gleiche Grundanordnung von Computer-Komponenten wie der erste Computer enthalten wird.
Nachdem der erste Computer 102 eine Kopie eines Computerprogramms 103 vom zweiten Computer 104 heruntergeladen hat, gibt es im Stand der Technik im Prinzip keine standardisierten Werkzeuge, die verfügbar sind, um dem Anwender des ersten Computers 102 zu helfen, die Integrität des heruntergeladenen Programms 103 zu verifizieren. Insbesondere ist es unter Verwendung von Werkzeugen des Standes der Technik praktisch unmöglich, zu bestimmen, ob das heruntergeladene Programm 103 zu einem Unterlauf oder Überlauf seines Stapels führen wird, oder ob das heruntergeladene Programm 103 die Dateien und andere Betriebsmittel des Computers des Anwenders verletzen wird, falls nicht der erste Computer den Quellcode des heruntergeladenen Programms untersucht.
Ein zweites Problem in bezug auf das Herunterladen von Computer-Software von einem Computer zu einem anderen betrifft das Übertragen der Computer-Software zwischen Computer-Plattformen, die verschiedene zugrunde liegende Maschinenanweisungsvorräte verwenden. Es gibt einige Beispiele des Standes der Technik von plattformunabhängigen Computer-Programmen und plattformunabhängigen Computer-Programmiersprachen. Dem Stand der Technik fehlen jedoch außerdem Werkzeuge zum effizienten Ausführen derartiger plattformunabhängiger Computer-Programme, während gegen die Verletzung der Datentyp-Benutzungsbeschränkungen und der Operandenstapel-Benutzungsbeschränkungen ein Schutz besteht.
Das Dokument R. A. MACLACHLAN: "THE PYTON COMPILER FOR CMV COMMON LISP", PROCEEDINGS OF THE CONFERENCE ON LISP AND FUNCTIONAL PROGRAMMING, 22.–24. Juni 1992, New York, USA, Bd. CONF. 7, 22. Juni 1992, lehrt die Prüfung des strict-Typs und das Austesten des kompilierten Programmcodes auf der Ebene der Quelle.
Die Erfindung ist in den Ansprüchen 1, 13 und 25 definiert.
Die vorliegende Erfindung betrifft einen Programminterpreter für Computer-Programme, die in einer Bytecode-Sprache geschrieben sind, die als die OAK-Sprache verkauft werden soll, die eine eingeschränkte Menge der datentypspezifischen Bytecodes verwendet. Alle verfügbaren Bytecodes des Quellcodes in der Sprache sind entweder (A) Stapeldaten, die Bytecodes verbrauchen, denen Datentyp-Beschränkungen zugeordnet sind, was die Datentypen anbelangt, die durch jeden derartigen Bytecode verarbeitet werden können, (B) verwenden keine Stapeldaten, beeinflussen aber den Stapel, indem sie entweder Daten eines bekannten Datentyps zum Stapel hinzufügen oder Daten ohne Rücksicht auf den Datentyp aus dem Stapel entfernen, oder (C) sie verwenden weder Stapeldaten noch fügen sie Daten zum Stapel hinzu.
Der Interpreter oder die vorliegende Erfindung gemäß einer bevorzugten Ausführungsform führt vor dem Ausführen irgendeines Bytecode-Programms eine Bytecode-Programm-Verifizierer-Prozedur aus, die die Integrität eines spezifizierten Programms verifiziert, indem sie jede Bytecode-Anweisung, die Daten vom falschen Typ für einen derartigen Bytecode verarbeiten würde, und jedes Programm aus einer Folge von Bytecode-Anweisungen, das einen Unterlauf oder Überlauf des Operandenstapels verursachen würde, kennzeichnet. Falls der Programm-Verifizierer irgendwelche Anweisungen findet, die die im voraus definierte Verwendung des Stapels und die Datentyp-Benutzungsbeschränkungen verletzen, wird die Ausführung des Programms durch den Interpreter verhindert.
Der Aspekt des Bytecode-Programm-Verifizierers der vorliegenden Erfindung gemäß einer bevorzugten Ausführungsform enthält einen virtuellen Operandenstapel für das vorübergehende Speichern der Stapelinformationen, die die in einem Programmoperandenstapel während der Ausführung eines spezifizierten Bytecode-Programms gespeicherten Daten anzeigen. Der Verifizierer verarbeitet das spezifizierte Programm, indem er jede Bytecode-Anweisung des Programms sequentiell ausführt, den virtuellen Operandenstapel aktualisiert, um die Anzahl, die Folge und die Datentypen der Daten anzuzeigen, die an jedem Punkt im Programm im Operandenstapel gespeichert werden würden. Der Verifizierer vergleicht außerdem die Informationen über den virtuellen Stapel mit den Datentyp-Beschränkungen, die jeder Bytecode-Anweisung zugeordnet sind, um zu bestimmen, ob der Operandenstapel während der Ausführung des Programms Daten enthalten würde, die mit den Datentyp-Beschränkungen der Bytecode-Anweisung inkonsistent sind, wobei er außerdem bestimmt, ob irgendwelche Bytecode-Anweisungen im spezifizierten Programm einen Unterlauf oder Überlauf des Operandenstapels verursachen würden.
Um eine ausführliche Analyse des Flusses der Folge der Anweisungen des Bytecode-Programms zu vermeiden und um zu vermeiden, dass die Bytecode-Anweisungen mehrmals verifiziert werden, werden alle Punkte (die als die Mehrfach-Einsprungpunkte bezeichnet werden) in dem spezifizierten Programm, denen unmittelbar vor der Ausführung zwei oder mehr verschiedene Bytecodes im Programm vorausgegangen sein können, gekennzeichnet. Vorzugsweise wird wenigstens einer der zwei oder mehr verschiedenen Bytecodes im Programm ein Sprung/Verzweigungs-Bytecode sein. Während der Vorverarbeitung des spezifizierten Programms nimmt der Verifizierer einen "Schnappschuss" des virtuellen Operandenstapels unmittelbar vor jedem Mehrfach-Einsprungpunkt auf (d. h. anschließend an irgendeine der vorhergehenden Bytecode-Anweisungen), vergleicht den Schnappschuss mit dem Zustand des virtuellen Operandenstapels nach der Verarbeitung jeder der anderen vorhergehenden Bytecode-Anweisungen für den gleichen Mehrfach-Einsprungpunkt und erzeugt einen Programmfehler, falls die Zustände des virtuellen Stapels nicht gleich sind.
Nach der Vorverarbeitung des Programms durch den Verifizierer führt der Interpreter, falls keine Programmfehler festgestellt wurden, das Programm aus, ohne die Operandenstapelüberlauf- und Operandenstapelunterlauf-Prüfungen auszuführen und ohne die Datentyp-Prüfungen an den im Operandenstapel ge speicherten Operanden auszuführen. Im Ergebnis wird die Geschwindigkeit der Ausführung des Programms in hohem Maße verbessert.
In einer weiteren Ausführungsform umfasst ein Verfahren zum Betreiben eines Computer-Systems die Schritte (A) Speichern eines Programms in einem Speicher, wobei das Programm eine Sequenz von Bytecodes enthält, wobei jede aus einer Menge von Bytecodes eine Operation an den Daten eines spezifischen Datentyps darstellt; wobei jeder Bytecode zugeordnete Datentyp-Einschränkungen an den Datentyp der Daten besitzt, die durch jeden Bytecode zu manipulieren sind; (B) vor der Ausführung des Programms Vorverarbeiten des Programms durch Bestimmen, ob die Ausführung irgendeines Bytecodes im Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würde, und Erzeugen eines Programmfehlersignals, wenn die Ausführung irgendeines Bytecodes in dem Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würden; (C) wenn die Vorverarbeitung des Programms nicht zur Erzeugung von Programmfehlersignals führt, Ermöglichen der Ausführung des Programms; und (D) wenn die Vorverarbeitung des Programms zur Erzeugung eines Programmfehlers führt, Verhindern der Ausführung des Programms.
Der Vorverarbeitungsschritt kann enthalten (B1) Bestimmen des Zustands eines virtuellen Stapels, der dem Programm zugeordnet ist, vor und nach der Ausführung jedes Bytecodes im Programm, wobei der Zustand des virtuellen Stapels die Datentyp-Werte für die Operanden speichert, die in einem Operandenstapel während der Ausführung des Programms gespeichert sein würden; und (B2) Bestimmen, ob die Ausführung irgendeines Bytecodes in dem Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würde, und Erzeugen eines Programmfehlersignals, wenn die Ausführung irgendeines Bytecodes im Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würde.
Ferner kann das Bytecode-Programm wenigstens eine Ausführungsschleife enthalten, wobei der Vorverarbeitungsschritt einen Schritt (B3) des Bestimmens, ob die Ausführung irgendeiner Schleife in dem Programm zu einer Nettohinzufügung oder -löschung von Operanden zu dem oder aus dem Operandenstapel führen würde, und zum Erzeugen eines Programmfehlersignals, wenn die Ausführung irgendeiner Schleife in dem Programm eine Nettohinzufügung oder -löschung von Operanden zu dem oder aus dem Operandenstapel erzeugen würde, enthalten kann.
In dieser Ausführungsform kann, wenn die Ausführung des Bytecode-Programms freigegeben worden ist, das Bytecode-Programm ausgeführt werden, ohne Unterlauf- und Überlauf-Prüfungen des Operandenstapels während der Ausführung des Bytecode-Programms auszuführen.
Wenn die Ausführung des Bytecode-Programms freigegeben worden ist, kann das Bytecode-Programm außerdem ausgeführt werden, ohne Datentypprüfungen an den Operanden, die im Operandenstapel gespeichert sind, während der Ausführung des Bytecode-Programms auszuführen.
Das Bytecode-Programm kann wenigstens eine Ausführungsschleife enthalten; der Schritt (B) kann die Schritte des Bestimmens des Zustands eines virtuellen Stapels, der dem Programm zugeordnet ist, vor und nach der Ausführung jedes Bytecodes im Programm, wobei der Zustand des virtuellen Stapels die Datentyp-Werte für die Operanden speichert, die während der Ausführung des Programms in einem Operandenstapel gespeichert sein würden; und Bestimmen, ob die Ausführung irgendeiner Schleife in dem Programm zu einer Nettohinzufügung oder -löschung von Operanden zu dem oder aus dem Operandenstapel führen würde, und zum Erzeugen eines Programmfehlersignals, wenn die Ausführung irgendeiner Schleife in dem Programm eine Nettohinzufügung oder -löschung von Operanden zu dem oder aus dem Operandenstapelerzeugen würde, enthalten.
Wenn hier die Ausführung des Bytecode-Programms freigegeben worden ist, kann das Bytecode-Programm ausgeführt werden, ohne während der Ausführung des Bytecode-Programms Unterlauf- und Überlaufprüfungen des Operandenstapels auszuführen.
Der Schritt (B) kann außerdem das Bestimmen enthalten, jedes Mal wenn zwei oder mehr Bytecodes in dem Programm Sprünge/Verzweigungen zu einer völlig gleichen Stelle in dem Programm umfassen, ob die Zustände des virtuellen Stapels vor der Ausführung jedes der Sprünge/jeder der Verzweigungen inkonsistent sind, und ein Programmfehlersignal erzeugen, wenn die Zustände des virtuellen Stapels inkonsistent sind.
Wenn hier die Ausführung des Bytecode-Programms freigegeben worden ist, kann das Bytecode-Programm ausgeführt werden, ohne während der Ausführung des Bytecode-Programms Prüfungen des Zustands des Operandenstapels auszuführen.
In einer weiteren Ausführungsform kann ein Computer-System einen Speicher zum Speichern eines Bytecode-Programms, wobei das Bytecode-Programm eine Sequenz von Bytecodes enthält, wobei jeder aus einer Menge von Bytecodes eine Operation an den Daten eines spezifischen Datentyps darstellt; wobei jeder Bytecode zugeordnete Datentyp-Einschränkungen an den Datentyp der Daten besitzt, die durch jeden Bytecode manipuliert werden; eine Datenverarbeitungseinheit zum Ausführen von im Speicher gespeicherten Programmen; einen Bytecode-Programm-Verifizierer, der im Speicher gespeichert ist, wobei der Bytecode-Programm-Verifizierer Datentyp-Prüfbefehle enthält, um zu bestimmen, ob die Ausführung irgendeines Bytecodes in dem Programm die Datentyp-Einschränkungen für den Bytecode verletzen würde, und um ein Programmfehlersignal zu erzeugen, wenn die Ausführung irgendeines Bytecodes im Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würde; und einen Bytecode-Programm-Interpreter, der an den Bytecode-Programm-Verifizierer gekoppelt ist, der das Bytecode-Programm nach der Verarbeitung des Bytecode-Programms durch den Bytecode-Programm-Verifizierer nur ausführt, wenn der Bytecode-Programm-Verifizierer keine Programmfehlersignale erzeugt, umfassen.
In diesem Computer-System kann der Bytecode-Programm-Verifizierer Stapelzustands-Verfolgungsbefehle, um den Zustand eines virtuellen Stapels, der dem Programm zugeordnet ist, vor und nach der Ausführung jedes Bytecodes in dem Programm zu bestimmen, wobei der Zustand des virtuellen Stapels die Datentyp-Werte für die Operanden speichert, die während der Ausführung des Programms in einem Operandenstapel gespeichert sein würden; und Datentyp-Prüfbefehle, um zu bestimmen, ob die Ausführung irgendeines Bytecodes in dem Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würden, und um ein Programmfehlersignal zu erzeugen, wenn die Ausführung irgendeines Bytecodes in dem Programm die Datentyp-Einschränkungen für diesen Bytecode verletzen würde, enthalten.
Der Bytecode-Programm-Verifizierer kann Stapel-Überlauf/Unterlauf-Prüfbefehle enthalten, um zu bestimmen, ob die Ausführung des Programms zu einem Unterlauf oder Überlauf des Operandenstapels führen würde, und um ein Programmfehlersignal erzeugen, wenn die Ausführung des Programms zu einem Unterlauf oder Überlauf des Programmstapels führen würde.
Hier kann der Bytecode-Programm-Interpreter Befehle enthalten, um das Bytecode-Programm auszuführen, ohne während der Ausführung des Bytecode-Programms Unterlauf- und Überlaufprüfungen des Operandenstapels auszuführen.
Der Bytecode-Programm-Interpreter kann Befehle enthalten, um das Bytecode-Programm auszuführen, ohne Datentypprüfungen an den von dem Bytecode-Programm verwendeten Operanden auszuführen.
Der Bytecode-Programm-Verifizierer kann Stapelstatus-Verfolgungsbe fehle, um den Zustand eines virtuellen Stapels, der dem Programm zugeordnet ist, vor und nach der Ausführung jedes Bytecodes in dem Programm zu bestimmen, wobei der Zustand des virtuellen Stapels Datentyp-Werte für die Operanden speichert, die während der Ausführung des Programms im Operandenstapel gespeichert sein würden; und Stapel-Überlauf/Unterlauf-Prüfbefehle, um zu bestimmen, ob die Ausführung des Programms zu einem Unterlauf oder Überlauf des Operandenstapels führen würde, und um ein Programmfehlersignal zu erzeugen, wenn die Ausführung des Programms zu einem Unterlauf oder Überlauf des Operandenstapels führen würde, enthalten.
Der Bytecode-Programm-Interpreter kann Mittel zum Ausführen des Bytecode-Programms enthalten, ohne während der Ausführung des Bytecode-Programms die Unterlauf- und Überlaufprüfungen des Operandenstapels auszuführen.
Der Bytecode-Programm-Verifizierer kann Sprung-/Verzweigungs-Prüfbefehle enthalten, um zu bestimmen, ob die Zustände des virtuellen Stapels vor der Ausführung jedes der Sprünge/jeder der Verzweigungen inkonsistent sind, wann immer zwei oder mehr Bytecodes in dem Programm Sprünge/Verzweigungen zu einer völlig gleichen Stelle in dem Programm umfassen, und um ein Programmfehlersignal zu erzeugen, falls die Zustände des virtuellen Stapels inkonsistent sind.
Hier kann der Bytecode-Programm-Interpreter Mittel enthalten, um das Bytecode-Programm auszuführen, ohne die Zustandsprüfungen des Operandenstapels während der Ausführung des Bytecode-Programms auszuführen.
Die beigefügten Zeichnungen, die in diese Beschreibung aufgenommen sind und einen Teil dieser bilden, veranschaulichen die Ausführungsformen der Erfindung, wobei sie zusammen mit der Beschreibung dazu dienen, die Prinzipien der Erfindung zu erklären, wobei:
1 zwei Computer darstellt, die über ein Netz miteinander verbunden sind.
2 stellt zwei Computer dar, die über ein Netz miteinander verbunden sind, wobei wenigstens einer von diesen einen Bytecode-Programm-Verifizierer gemäß der vorliegenden Erfindung enthält.
3 stellt die Datenstrukturen dar, die durch einen Bytecode-Verifizierer während der Verifikation eines Bytecode-Programms gemäß der vorliegenden Erfindung aufrechterhalten werden.
4 stellt einen Ablaufplan des Prozesses der Verifikation des Bytecode- Programms in der bevorzugten Ausführungsform der vorliegenden Erfindung dar.
5 stellt einen Ablaufplan des Prozesses des Bytecode-Programm-Interpreters in der bevorzugten Ausführungsform der vorliegenden Erfindung dar. Nun wird ausführlich auf die bevorzugten Ausführungsformen der Erfindung Bezug genommen, wobei Beispiele von diesen in den beigefügten Zeichnungen veranschaulicht sind. Während die Erfindung im Zusammenhang mit den bevorzugten Ausführungsformen beschrieben wird, wird es selbstverständlich sein, dass mit ihnen nicht beabsichtigt ist, die Erfindung auf diese Ausführungsformen einzuschränken. Im Gegensatz dazu ist beabsichtigt, dass die Erfindung Alternativen, Modifikationen und Äquivalente, die in den Umfang der Erfindung aufgenommen werden können, wie durch die beigefügten Ansprüche definiert ist, einschließt.
In einem verteilten Computer-System 200, wie in 2 gezeigt ist, ist ein erster Computerknoten 202 mit einem zweiten Computerknoten 204 über ein Computer-Kommunikationsnetz, wie z. B. das Internet 220, verbunden. Der erste Computerknoten 202 enthält eine Zentraleinheit 206, eine Anwenderschnittstelle 208, einen Hauptspeicher (RAM) 210, einen Sekundärspeicher (Plattenspeicher) 212 und ein Modem oder eine andere Kommunikationsschnittstelle 214, das bzw. die den ersten Computerknoten 202 mit dem Computer-Kommunikationsnetz 220 verbindet. Der Plattenspeicher 212 speichert die Programme für die Ausführung durch den Prozessor 206, wobei wenigstens eines von diesen ein Bytecode-Programm 221 ist, das in ausführbarer Form vorliegt. Für die Zwecke dieser Beschreibung wird angenommen, dass der erste Computerknoten 202 das Bytecode-Programm 221 vom zweiten Computerknoten 204 über das Computer-Kommunikationsnetz 220 unter Verwendung der Dateiübertragungsprotokolle empfängt, die den Fachleuten wohl bekannt sind.
In der bevorzugten Ausführungsform ist das Bytecode-Programm als eine OAK-Anwendung geschrieben, die, wenn sie kompiliert oder interpretiert wird, zu einer Folge von ausführbaren Anweisungen führen wird. Eine Auflistung aller Bytecode-Anweisungen des Quellcodes im OAK-Anweisungsvorrat ist in der Tabelle 1 bereitgestellt. Der OAK-Anweisungsvorrat ist durch Bytecode-Anweisungen charakterisiert, die datentypspezifisch sind. Spezifisch unterscheidet der OAK-Anweisungsvorrat die gleichen Basisoperationen an verschiedenen ursprünglichen Datentypen durch das Bezeichnen getrennter Operationscodes. Demzufolge sind mehrere Bytecodes innerhalb des Anweisungsvorrats enthalten, um die gleiche Grundfunktion auszuführen (z. B. um zwei Zahlen zu addieren), wobei jeder derar tige Bytecode verwendet wird, um lediglich die Daten eines entsprechenden verschiedenen Datentyps zu verarbeiten. Außerdem ist der OAK-Anweisungsvorrat für Anweisungen wichtig, die nicht enthalten sind. Es gibt z. B. im Anweisungsvorrat der OAK-Sprache keine Anweisungen für einen "berechneten Sprung", und es gibt keine Anweisungen, um die Bezugnahme auf ein Objekt zu modifizieren oder um neue Bezugnahmen auf ein Objekt zu erzeugen (die von dem Kopieren einer bestehenden Bezugnahme auf ein Objekt verschieden sind). Sowohl diese zwei Beschränkungen des OAK-Anweisungsvorrats als auch andere helfen, zu sichern, dass irgendein Bytecode-Programm, das die Daten in einer Weise verwendet, die mit den datentypspezifischen Anweisungen im OAK-Anweisungsvorrat konsistent sind, die Integrität eines Computersystems eines Anwenders nicht verletzen wird.
In der bevorzugten Ausführungsform sind die verfügbaren Datentypen ganze Zahl, lange ganze Zahl, kurze ganze Zahl (ganze 16-Bit-Zahl mit Vorzeichen), Gleitkommazahl mit einfacher Genauigkeit, Gleitkommazahl mit doppelter Genauigkeit, Byte, Zeichen und Objektzeiger (der manchmal hierin als Bezugnahme auf ein Objekt bezeichnet wird). Der Datentyp der "Bezugnahme auf ein Objekt" enthält eine praktisch unbeschränkte Anzahl von Daten-Untertypen, weil jeder Datentyp der "Bezugnahme auf ein Objekt" eine Spezifikation einer Objektklasse als Teil des Datentyps enthalten kann. Außerdem sind die in den Programmen verwendeten Konstanten ebenfalls mit Datentypen versehen, wobei die verfügbaren Datentypen der Konstanten in der bevorzugten Ausführungsform die oben erwähnten Datentypen umfassen, außerdem gibt es Klasse, Feldbezugnahme, Verfahrensbezugnahme, Zeichenkette und Asciz, wobei alle von ihnen zwei oder mehr Bytes darstellen, die einen spezifischen Zweck besitzen.
Die wenigen Bytecodes, die vom Datentyp unabhängig sind, führen Stapelmanipulationsfunktionen aus, wie z. B. (A) Duplizieren von einem oder mehreren Wörtern im Stapel und Anordnen dieser an spezifischen Stellen innerhalb des Stapels, dadurch Erzeugen von mehreren Stapelelementen des bekannten Datentyps, oder (B) Löschen von einem oder mehreren Elementen aus dem Stapel. Ein paar andere vom Datentyp unabhängige Bytecodes verwenden keinerlei Wörter im Stapel und lassen den Stapel unverändert oder sie fügen Wörter zum Stapel hinzu, ohne irgendeines der Wörter zu verwenden, die sich vorausgehend im Stapel befanden. Diese Bytecodes besitzen keine Datentyp-Beschränkungen in Bezug auf die Stapelinhalte vor ihrer Ausführung, wobei alle außer ein paar die Inhalte des Stapels modifizieren und folglich den Prozess der Verifikation des Pro gramms beeinflussen.
Der zweite Computerknoten 204, von dem hier angenommen wird, dass er als ein Datei- oder anderer Informations-Server konfiguriert ist, enthält eine Zentraleinheit 218, eine Anwenderschnittstelle 228, einen Hauptspeicher (RAM) 222, einen Sekundärspeicher (Plattenspeicher) 224 und ein Modem oder eine andere Kommunikationsschnittstelle 234, das bzw. die den zweiten Computerknoten mit dem Computer-Kommunikationsnetz 220 verbindet. Der Plattenspeicher 224 speichert die Programme für die Ausführung durch den Prozessor 218 und/oder die Verteilung zu anderen Computerknoten.
Die ersten und zweiten Computerknoten 202 und 204 können verschiedene Computer-Plattformen und Betriebssysteme 236, 237 verwenden, sodass die Objektcode-Programme, die auf irgendeinem der zwei Computerknoten ausgeführt werden, nicht auf dem anderen ausgeführt werden können. Der Server-Knoten 204 könnte z. B. ein Computer von Sun Microsystems sein, der ein Unix-Betriebssystem verwendet, während der Knoten 202 des Anwender-Arbeitsplatzrechners ein IBM-kompatibler Computer sein kann, der einen 80486-Mikroprozessor und ein DOS-Betriebssystem von Microsoft verwendet. Außerdem könnten andere Anwender-Arbeitsplatzrechner, die an das gleiche Netz gekoppelt sind und die den gleichen Server 204 verwenden, eine Vielzahl verschiedener Computer-Plattformen und eine Vielzahl von Betriebssystemen verwenden.
In der Vergangenheit würde ein Server 204, der für das Verteilen von Software in einem Netz verwendet wird, das Computer von vielen Typen aufweist, verschiedene Software-Bibliotheken für jeden der verschiedenen Typen der Computer-Plattformen speichern (z. B. Unix, Windows, DOS, Macintosh usw.). Folglich könnten in jeder Bibliothek verschiedene Versionen des gleichen Computer-Programms gespeichert sein. Unter Verwendung der vorliegenden Erfindung könnten jedoch viele Computerprogramme durch einen derartigen Server unter Verwendung gerade einer einzelnen Bytecode-Version des Programms verteilt werden.
Wie in 2 gezeigt ist, speichert der erste Computerknoten 202 in seinem Sekundärspeicher 212 ein Bytecode-Verifiziererprogramm 240 zum Verifizieren der Integrität der spezifizierten Bytecode-Programme und einen Bytecode-Interpreter 242 zum Ausführen der spezifizierten Bytecode-Programme. Alternativ oder zusätzlich kann der erste Computerknoten 202 einen Bytecode-Kompilierer 244 zum Umsetzen eines verifizierten Bytecode-Programms in ein Objektcode-Programm für die anschließend effizientere Ausführung des Bytecode-Programms 221 durch den Interpreter 244 speichern.
Der Bytecode-Verifizierer 240 ist ein ausführbares Programm, das die Kompatibilität des Datentyps des Operanden und die richtigen Manipulationen des Stapels in einem spezifizierten Bytecode-Programm (Quellprogramm) 221 vor der Ausführung des Bytecode-Programms 221 durch den Prozessor 206 unter der Steuerung des Bytecode-Interpreters 242 verifiziert. Jedes Bytecode-Programm 103 besitzt einen zugeordneten Verifikationsstatuswert 245, der anfangs auf falsch gesetzt ist, wenn das Programm von einem anderen Ort heruntergeladen wird. Der Verifikationsstatuswert 245 für das Programm wird durch den Bytecode-Verifizierer 240 nur auf wahr gesetzt, nachdem für das Programm verifiziert worden ist, dass es nicht durch irgendeine Prüfung des Datentyps und der Stapelverwendung fällt, die durch den Verifizierer 240 ausgeführt werden.
Während der normalen Ausführung eines Programms durch einen Interpreter muss der Interpreter kontinuierlich den Operandenstapel nach Überläufen (d. h. dem Hinzufügen von mehr Daten zum Stapel als der Stapel speichern kann) und Unterläufen (d. h. dem Versuchen, Daten aus dem Stapel auszuspeichern, wenn der Stapel leer ist) überwachen. Eine derartige Überwachung des Stapels muss normalerweise für alle Anweisungen ausgeführt werden, die den Stapelstatus ändern (was die meisten Anweisungen enthält). Für viele Programme sind die durch den Interpreter ausgeführten Anweisungen zur Überwachung des Stapels für etwa 80% der Ausführungszeit eines interpretierten Computer-Programms verantwortlich.
Außerdem kann das heruntergeladene Bytecode-Programm Fehler enthalten, die Datentypen von Operanden einschließen, die den Datentyp-Beschränkungen der Anweisungen, die diese Operanden verwenden, nicht entsprechen, was einen Ausfall des Programms während der Ausführung verursachen kann. Noch schlimmer könnte ein Bytecode-Programm versuchen, Bezugnahmen auf Objekte zu erzeugen (z. B. durch das Laden einer berechneten Zahl in den Operandenstapel und dann durch das Versuchen, die berechnete Zahl als einen Objektbezeichner zu verwenden) und dadurch die Sicherheit und/oder die Integrität des Computers des Anwenders zu verletzen.
Die Verwendung des Bytecode-Verifizierers 240 gemäß der vorliegenden Erfindung ermöglicht die Verifizierung der Integrität eines Bytecode-Programms und erlaubt die Verwendung eines Interpreters 242, der die üblichen Anweisungen zur Überwachung des Stapels während der Ausführung des Programms nicht ausführt, wobei dadurch der Prozess der Interpretation des Programms im hohen Maße beschleunigt wird.
Der Bytecode-Programm-Verifizierer
In 3 wird die Ausführung des Bytecode-Programm-Verifizierers 240 im Zusammenhang mit einem speziellen Bytecode-Programm 340 erklärt. Der Verifizierer 240 verwendet ein paar temporäre Datenstrukturen, um die Informationen zu speichern, die er während des Verifikationsprozesses benötigt. Insbesondere verwendet der Verifizierer 240 einen Stapelzähler 342, einen virtuellen Stapel 344, ein virtuelles lokales Variablenfeld 345 und eine Stapelschnappschuss-Speicherstruktur 346.
Der Stapelzähler 342 wird durch den Verifizierer 240 aktualisiert, wie er die Manipulationen des virtuellen Stapels verfolgt, um die aktuelle Anzahl der Einträge im virtuellen Stapel 320 widerzuspiegeln.
Der virtuelle Stapel 344 speichert die Datentypinformationen, die jedes Datenelement betreffen, das durch das Bytecode-Programm 340 während der tatsächlichen Ausführung im Operandenstapel gespeichert wird. In der bevorzugten Ausführungsform wird der virtuelle Stapel 344 in der gleichen Weise wie ein richtiger Stapel verwendet, außer, dass der virtuelle Stapel 344 anstatt des Speicherns der tatsächlichen Daten und Konstanten einen Datentyp-Anzeigewert für jedes Datenelement speichert, das während der tatsächlichen Ausführung des Programms im Operandenstapel gespeichert werden wird. Falls folglich während der tatsächlichen Ausführung der Stapel z. B. drei Werte speichern würde:
HandleToObjectA
5
1
werden die entsprechenden Einträge im virtuellen Stapel
R
I
I
sein, wobei "R" im virtuellen Stapel eine Bezugnahme auf ein Objekt anzeigt, während jedes "I" im virtuellen Stapel eine ganze Zahl anzeigt. Außerdem würde der Stapelzähler 342 in diesem Beispiel einen Wert von 3 speichern, der den drei Werten entspricht, die im virtuellen Stapel 344 gespeichert sind.
Die Daten jedes möglichen Datentyps sind einem entsprechenden Markierungswert des virtuellen Stapels zugeordnet, z. B.: ganze Zahl (I), lange ganze Zahl (L), Gleitkommazahl mit einfacher Genauigkeit (F), Gleitkommazahl mit doppelter Genauigkeit (D), Byte (B), kurze ganze Zahl (S) und Bezugnahme auf ein Objekt (R). Der Markierungswert für eine Bezugnahme auf ein Objekt wird oft einen Objektklassenwert enthalten (z. B. R: Punkt, wobei "Punkt" eine Objektklasse ist).
Das virtuelle lokale Variablenfeld 345 dient der gleichen Grundfunktion wie der virtuelle Stapel 344. Das heißt, es wird verwendet, um die Datentyp-Informationen für die lokalen Variablen zu speichern, die durch das spezifizierte Bytecode-Programm verwendet werden. Weil die Daten oft durch Programme zwischen lokalen Variablen und dem Operandenstapel übertragen werden, können die Bytecode-Anweisungen, die derartige Datenübertragungen ausführen und ansonsten lokale Variablen verwenden, überprüft werden, um zu sichern, dass die lokalen Variablen, auf die durch jede Bytecode-Anweisung zugegriffen wird, mit den Datentyp-Benutzungsbeschränkungen für diese Bytecode-Anweisungen konsistent sind.
Während der Verarbeitung des spezifizierten Bytecode-Programms für jedes Datenelement, das für die Verarbeitung durch eine Bytecode-Anweisung aus dem Stapel ausgespeichert wird, speichert der Verifizierer die gleiche Anzahl des Datentypwerts aus dem virtuellen Stapel 342 aus und vergleicht die Datentypwerte mit den Datentyp-Anforderungen des Bytecodes. Für jedes Datenelement, das durch eine Bytecode-Anweisung in den Stapel eingespeichert wird, speichert der Verifizierer einen entsprechenden Datentypwert in den virtuellen Stapel ein.
Ein Aspekt der Programmverifikation gemäß der vorliegenden Erfindung ist die Verifikation, dass die Anzahl und der Datentyp der Operanden im Status des Operandenstapels jedes Mal gleich ist, wenn eine spezielle Anweisung ausgeführt wird. Wenn einer speziellen Bytecode-Anweisung bei der Ausführung unmittelbar zwei oder mehr verschiedene Anweisungen vorausgehen können, dann muss der Status des virtuellen Stapels unmittelbar nach der Verarbeitung jeder dieser verschiedenen Anweisungen verglichen werden. Normalerweise wird wenigstens eine der verschiedenen vorhergehenden Anweisungen eine bedingte oder unbedingte Sprung- oder Verzweigungsanweisung sein. Eine Folge der obigen Anforderung der "Konsistenz des Stapels" ist, dass jede Programmschleife nicht zu einer Netto-Hinzufügung oder -Verringerung der Anzahl der Operanden führen darf, die im Operandenstapel gespeichert sind.
Die Stapelschnappschuss-Speicherstruktur 346 wird verwendet, um die "Schnappschüsse" des Stapelzählers 342 und des virtuellen Stapels 344 zu speichern, um den effizienten Vergleich des Status des virtuellen Stapels an verschie denen Punkten im Programm zu ermöglichen. Jeder gespeicherte Stapelschnappschuss weist diese Form auf:
SC, DT1, DT2, DT3, ..., DTn
wobei SC der Wert des Stapelzählers ist, DT1 ist der erste Datentypwert im virtuellen Operandenstapel, DT2 ist der zweite Datentypwert im virtuellen Operandenstapel usw. bis DTn, das der Datentypwert für das letzte mögliche Element im virtuellen Operandenstapel ist.
Die Stapelschnappschuss-Speicherstruktur 346 wird in einen Verzeichnisabschnitt 348 und in einen Schnappschuss-Speicherabschnitt 350 binär verzweigt. Der Verzeichnisabschnitt 348 wird verwendet, um die Kennzeichnungen der Zielanweisungen zu speichern (z. B. die absolute oder relative Adresse jeder Zielanweisung), während der Schnappschussabschnitt 350 verwendet wird, um die Schnappschüsse des virtuellen Stapels 344 zu speichern, die den Kennzeichnungen der Zielanweisung zugeordnet sind.
Die "Ziel"-Anweisungen sind definiert, dass sie alle Bytecode-Anweisungen sind, die das Ziel einer Sprung- oder Verzweigungsanweisung sein können. Eine bedingte Verzweigungsanweisung enthält z. B. eine Bedingung (die erfüllt sein kann oder nicht) und eine Verzweigung, die anzeigt, zu welcher Stelle (Ziel) im Programm die Ausführung im Fall, dass die Bedingung erfüllt ist, "springen" soll. Bei der Auswertung einer bedingten Sprunganweisung verwendet der Verifizierer 300 die Stapelschnappschuss-Speicherstruktur 346, um sowohl die Kennung der Zielstelle (im Verzeichnisabschnitt 348) und den Status des virtuellen Stapels 344 (im Schnappschussabschnitt 350) gerade vor dem Sprung zu speichern. Der Betrieb der Stapelschnappschuss-Speicherstruktur 346 wird im Folgenden im Zusammenhang mit der Beschreibung der Ausführung des Bytecode-Verifiziererprogramms ausführlicher erklärt.
Wie vorausgehend beschrieben wurde, enthält das Bytecode-Programm 350 mehrere datentypspezifische Anweisungen, wobei jede von diesen durch den Verifizierer 300 der vorliegenden Erfindung ausgewertet wird. Das Bytecode-Programm 350 enthält Anweisungen für Stapelmanipulationen 352 und 354 (speichere eine ganze Zahl in den Stapel ein bzw. speichere eine ganze Zahl aus dem Speicher aus), einen Vorwärtssprung 356 und sein zugeordnetes Ziel 364, einen Rückwärtssprung 366 und sein zugeordnetes Ziel 362 und eine Laufanweisungsschleife 358 und ihr zugeordnetes Ende 360 (das abhängig vom Typ der Laufanweisungsschleife eine unbedingte oder bedingte Verzweigungsanweisung sein kann). Weil der Verifizierer 240 der bevorzugten Ausführungsform der vorliegenden Erfindung lediglich versucht, die Stapelmanipulationen und die Kompatibilitäten der Datentypen zu verifizieren, kann der Betrieb des Bytecode-Verifizierers unter Verwendung dieses repräsentativen Anweisungsvorrats erklärt werden.
Nun wird unter Bezugnahme auf die 4A–4G und den Anhang 1 die Ausführung des Bytecode-Verifiziererprogramms 240 ausführlich beschrieben. Der Anhang 1 listet eine Pseudocode-Darstellung des Verifiziererprogramms auf. Der im Anhang 1 verwendete Pseudocode ist im Prinzip eine Computer-Sprache, die die universellen Konventionen für Computer-Sprachen verwendet. Während der verwendete Pseudocode lediglich für die Zwecke dieser Beschreibung erfunden worden ist, ist er entworfen worden, damit er für irgendeinen in der Technik sachkundigen Computerprogrammierer leicht verständlich ist.
Wie in 4A gezeigt ist, wird das heruntergeladene Bytecode-Programm für die Verarbeitung in den Bytecode-Verifizierer 300 geladen (400). Der Verifizierer 300 erzeugt (402) den virtuellen Stapel 344 und erzeugt das virtuelle lokale Variablenfeld 345, indem er Felder aus Stellen im Speicher bezeichnet, um Informationen über die Operanden und den Datentyp der lokalen Variable zu speichern. Ähnlich erzeugt (404) der Verifizierer die Stapelschnappschuss-Speicherstruktur, indem er ein Feld aus Stellen im Speicher bezeichnet, um die Schnappschussinformationen zu speichern. Schließlich bezeichnet (406) der Verifizierer ein Register, das als ein Stapelzähler 342 wirken soll, um die Anzahl der Einträge im virtuellen Stapel zu verfolgen.
Es wird ein erster Durchlauf durch das Bytecode-Programm ausgeführt, um die Zielinformationen zu extrahieren, die den bedingten und unbedingten Sprüngen und den Schleifenanweisungen zugeordnet sind. In diesem ersten Durchlauf verarbeitet der Verifizierer 300 alle Anweisungen sequentiell (Schritte 408, 410, 412), wobei für jede Anweisung, die ein bedingter oder unbedingter Sprung ist (Schritt 414), eine Darstellung der Zielstelle für den Sprung im Verzeichnisabschnitt 348 der Stapelschnappschuss-Speicherstruktur 346 gespeichert wird (Schritt 416), falls nicht die Zielstelle bereits im Verzeichnis 348 gespeichert worden ist (Schritt 418). Die absolute oder relative Adresse der Zielanweisung kann z. B. im nächsten verfügbaren Schlitz des Verzeichnisses 348 gespeichert werden. Alle anderen Typen der Bytecode-Anweisungen werden in diesem ersten Durchlauf ignoriert.
Nachdem alle Anweisungen im Programm verarbeitet worden sind, wird das Verzeichnis 348 vorzugsweise sortiert, um die im Verzeichnis notierten Ziel stellen in die sequentielle Reihenfolge der Adressen zu bringen.
In 3 ist für die Zwecke der Veranschaulichung die Stapelschnappschuss-Speicherstruktur 346 mit den Informationen geladen worden, die im Verzeichnisabschnitt 348 gespeichert worden wären, wenn der erste Durchlauf der Verifikation anhand der Bytecode-Anweisungen abgeschlossen worden wäre, die im Bytecode-Programm 350 gezeigt sind. Spezifisch ist der Verzeichnisabschnitt mit den Adressen geladen worden, die allen Zielen der bedingten und unbedingten Sprünge zugeordnet sind, die im Bytecode-Programm resident sind.
In 4B wird ein zweiter Durchlauf durch das Bytecode-Programm eingeleitet, um die richtige Verwendung des Operandenstapels und der Datentypen durch das Bytecode-Programm zu verifizieren. Die erste Anweisung des Bytecode-Programms wird ausgewählt (430), wobei der Verifizierer zuerst überprüft (432), um festzustellen, ob die Adresse für die ausgewählte Anweisung im Verzeichnisabschnitt 348 der Stapelschnappschuss-Speicherstruktur 346 im obenbeschriebenen ersten Durchlauf gespeichert worden ist.
Falls sich die Adresse der ausgewählten Anweisung im Verzeichnis 348 befindet, wodurch angezeigt wird, dass die ausgewählte Anweisung das Ziel eines bedingten oder unbedingten Sprungs ist, prüft (434) der Verifizierer, um festzustellen, ob ein zugeordneter Stapelschnappschuss im Schnappschussabschnitt 350 der Stapelschnappschuss-Speicherstruktur 346 gespeichert worden ist. Wenn ein Stapelschnappschuss nicht gespeichert worden ist (wodurch angezeigt wird, dass die Anweisung ein Ziel eines Rückwärtssprungs ist), dann werden die Inhalte des virtuellen Stapels und Stapelzählers in der Stapelschnappschuss-Speicherstruktur 346 gespeichert (436). Der Schnappschuss enthält die Informationen über den Status des virtuellen Stapels gerade vor der Ausführung der Anweisung, die verarbeitet wird, einschließlich eines Datentypwerts für jedes Datenelement, das in den Stapel eingespeichert worden ist.
Wenn für die gegenwärtig ausgewählte Anweisung ein Stapelschnappschuss gespeichert worden ist (wodurch angezeigt wird, dass eine Sprunganweisung, die dieser Zielanweisung zugeordnet ist, bereits verarbeitet worden ist), dann vergleicht (438) der Verifizierer die Informationen des Schnappschusses des virtuellen Stapels, die im Schnappschussabschnitt 350 der Stapelschnappschuss-Speicherstruktur 346 für die gegenwärtig ausgewählte Anweisung gespeichert sind, mit dem aktuellen Zustand des virtuellen Stapels. Falls der Vergleich zeigt, dass der aktuelle Zustand und der Schnappschuss nicht übereinstimmen, wird eine Fehlernachricht oder ein Fehlersignal erzeugt (440) die bzw. das die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung des Stapelstatus aufgetreten ist. In der bevorzugten Ausführungsform wird sich eine Nichtübereinstimmung ergeben, falls der aktuelle virtuelle Stapel und der Schnappschuss nicht die gleiche Anzahl oder die gleichen Typen der Einträge enthalten. Der Verifizierer wird dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (442). Das Setzen des Verifikationsstatuswertes 245 für das Programm auf falsch verhindert die Ausführung des Programms durch den Bytecode-Interpreter 242 (2).
Wenn der aktuelle virtuelle Stapel und der gespeicherte Stapelschnappschuss für die aktuelle Anweisung übereinstimmen (438), dann wird der Verifizierer den Verifikationsprozess fortsetzen und beginnend im Schritt 450 die einzelne Anweisung analysieren, wie im Folgenden beschrieben ist.
Falls die Adresse der gegenwärtig ausgewählten Anweisung nicht innerhalb des Verzeichnisabschnitts 348 der Stapelschnappschuss-Speicherstruktur 346 gefunden wird, oder falls keine Nichtübereinstimmung eines Stapelstatus erfasst wird, führt der Verifizierer abhängig von der Stapelverwendung und der Funktion der speziellen Anweisungen ausgewählte Prüfungen aus einer Folge von Prüfungen an der Anweisung aus.
In 4C betrifft die erste auszuführende Prüfung die Anweisungen, die Daten aus dem Operandenstapel ausspeichern. Falls die gegenwärtig ausgewählte Anweisung Daten aus dem Stapel ausspeichert (450) wird der Stapelzähler kontrolliert (452), um zu bestimmen, ob sich ausreichend Daten im Stapel befinden, um die Anforderungen zur Ausspeicherung von Daten der Anweisung zu erfüllen.
Falls der Operandenstapel für die gegenwärtige Anweisung ungenügend Daten besitzt (452), dies wird als Stapelunterlauf bezeichnet, wird in diesem Fall ein Fehlersignal oder eine Fehlernachricht erzeugt (454), das bzw. die die Stelle im Programm kennzeichnet, an der der Stapelunterlauf erfasst wurde. Außerdem wird der Verifizierer dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (456).
Falls kein Stapelunterlauf-Zustand erfasst wird, wird der Verifizierer die vorausgehend im virtuellen Stapel gespeicherten Informationen über den Datentypcode mit den Datentyp-Anforderungen (falls es welche gibt) der gegenwärtig ausgewählten Anweisung vergleichen (458). Falls der Operationscode der Anweisung, die analysiert wird, z. B. eine ganzzahlige Addition eines aus dem Stapel ausgespeicherten Wertes erfordert, wird der Verifizierer die Operandeninformatio nen des Elements im virtuellen Stapel, das ausgespeichert wird, vergleichen, um sich zu überzeugen, dass es den richtigen Datentyp aufweist, nämlich ganze Zahl. Wenn der Vergleich zu einer Übereinstimmung führt, löscht (460) der Verifizierer die Informationen aus dem virtuellen Stapel, der dem Eintrag zugeordnet ist, der ausgespeichert wird, wobei er den Stapelzähler 342 aktualisiert, um die Anzahl der aus dem virtuellen Stapel 344 ausgespeicherten Einträge widerzuspiegeln.
Wenn zwischen den gespeicherten Operandeninformationen im ausgespeicherten Eintrag aus dem virtuellen Stapel 344 und den Datentyp-Anforderungen der gegenwärtig ausgewählten Anweisung eine Nichtübereinstimmung erfasst wird (458), dann wird eine Nachricht erzeugt (462), die die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung aufgetreten ist. Der Verifizierer wird dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (456). Dies schließt den Verifikationsprozess des Ausspeicherns ab.
In 4D wird, falls die gegenwärtig ausgewählte Anweisung Daten in den Stapel einspeichert (470), der Stapelzähler kontrolliert (472), um zu bestimmen, ob es im Stapel ausreichend Raum gibt, die Daten zu speichern, die die ausgewählte Anweisung in den Stapel einspeichern wird. Falls der Operandenstapel ungenügend Raum besitzt, um die durch die gegenwärtige Anweisung in den Stapel einzuspeichernden Daten zu speichern (472), dies wird als ein Stapelüberlauf bezeichnet, wird in diesem Fall ein Fehlersignal oder eine Fehlernachricht erzeugt (474), das bzw. die die Stelle im Programm kennzeichnet, an der der Stapelunterlauf erfasst wurde. Außerdem wird dann der Verifizierer einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozeß abbrechen (476).
Falls kein Stapelüberlauf-Zustand erfasst wird, wird der Verifizierer für jedes durch die gegenwärtig ausgewählte Anweisung in den Stapel einzuspeichernde Datenelement einen Eintrag zum virtuellen Stapel hinzufügen (478), der den Typ der Daten (des Operanden) anzeigt, die (während der tatsächlichen Ausführung des Programms) in den Operandenstapel einzuspeichern sind. Diese Informationen werden aus den datentypspezifischen Operationscodes abgeleitet, die im Bytecode-Programm der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden. Der Verifizierer aktualisiert außerdem den Stapelzähler 342, um den hinzugefügten Eintrag oder die hinzugefügten Einträge im virtuellen Stapel widerzuspiegeln. Dies schließt den Prozess der Verifikation des Einspeicherns in den Stapel ab.
In 4E wird, falls die gegenwärtig ausgewählte Anweisung einen bedingten oder unbedingten Sprung oder eine bedingte oder unbedingte Verzweigung vorwärts im Programm über den normalen sequentiellen Schrittbetrieb hinaus verursacht (Schritt 480), der Verifizierer zuerst überprüfen (482), um festzustellen, ob ein Schnappschuss für die Zielstelle der Sprunganweisung in der Stapelschnappschuss-Speicherstruktur 346 gespeichert ist. Wenn ein Stapelschnappschuss nicht gespeichert worden ist, dann wird die Konfiguration des virtuellen Stapels (anschließend an irgendwelche Aktualisierungen des virtuellen Stapels, die dem Sprung zugeordnet sind) in der Stapelschnappschuss-Speicherstruktur 346 an einer Stelle gespeichert (484), die der Zielprogrammstelle zugeordnet ist. Es wird angemerkt, dass irgendwelche Operationen des Ausspeicherns in den Stapel, die dem Sprung zugeordnet sind, durch den vorausgehend ausgeführten Schritt 460 bereits im virtuellen Stapel widergespiegelt worden sind (siehe 4C).
Wenn ein Stapelschnappschuss gespeichert worden ist (wodurch angezeigt wird, dass ein anderer Einsprungpunkt, der dieser Zielanweisung zugeordnet ist, bereits verarbeitet worden ist), dann vergleicht (486) der Verifizierer die Informationen des Schnappschusses des virtuellen Stapels, die im Schnappschussabschnitt 340 der Stapelschnappschuss-Speicherstruktur 346 gespeichert sind, mit dem aktuellen Zustand des virtuellen Stapels. Wenn der Vergleich zeigt, dass der aktuelle Zustand und der Schnappschuss nicht übereinstimmen, dann wird eine Fehlernachricht erzeugt (488), die die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung des Stapelstatus aufgetreten ist. In der bevorzugten Ausführungsform wird sich eine Nichtübereinstimmung ergeben, falls der aktuelle virtuelle Stapel und der Schnappschuss nicht die gleiche Anzahl oder die gleichen Typen der Einträge enthalten. Außerdem wird sich eine Nichtübereinstimmung ergeben, falls einer oder mehrere Datentypwerte im aktuellen virtuellen Stapel nicht mit den entsprechenden Datentypwerten im Schnappschuss übereinstimmen. Dann wird der Verifizierer einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (490). Wenn im Schritt 486 eine Übereinstimmung des Stapelstatus erfasst wird, dann setzt der Verifizierer die Verarbeitung im Schritt 500 fort (4F).
Wenn in 4F die gegenwärtig ausgewählte Anweisung einen bedingten oder unbedingten Sprung oder eine bedingte oder unbedingte Verzweigung rückwärts im Programm verursacht (Schritt 500), dann vergleicht (502) der Verifizierer die Informationen über den Schnappschuss des virtuellen Stapels, die im Schnappschussabschnitt 340 der Stapelschnappschuss-Speicherstruktur 346 gespeichert sind, die dem Ziel des Rückwärtssprungs zugeordnet ist (das im Schritt 436 bereits gespeichert worden ist), mit dem aktuellen Zustand des virtuellen Stapels. Wenn der Vergleich zeigt, dass der aktuelle Zustand und der Schnappschuss nicht übereinstimmen, dann wird eine Fehlernachricht erzeugt (504), die die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung des Stapelstatus aufgetreten ist. In der bevorzugten Ausführungsform wird sich eine Nichtübereinstimmung ergeben, falls der aktuelle virtuelle Stapel und der Schnappschuss nicht die gleiche Anzahl oder die gleichen Typen von Einträgen enthalten oder falls irgendein Datentypeintrag im aktuellen virtuellen Stapel nicht mit dem entsprechenden Datentypeintrag im Schnappschuss übereinstimmt. Der Verifizierer wird dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (506).
Wenn eine Übereinstimmung des Stapelstatus erfasst wird (im Schritt 502) oder wenn die Anweisung kein Rückwärtssprung ist (im Schritt 500), dann setzt der Verifizierer die Verarbeitung im Schritt 510 fort.
Falls die gegenwärtig ausgewählte Anweisung die Daten aus einer lokalen Variable liest (510), wird der Verifizierer die vorausgehend in der entsprechenden virtuellen lokalen Variable gespeicherten Informationen über den Datentypcode mit den Datentyp-Anforderungen (falls es welche gibt) der gegenwärtig ausgewählten Anweisungen vergleichen (512). Wenn zwischen den in der virtuellen lokalen Variable gespeicherten Datentyp-Informationen und den Datentyp-Anforderungen der gegenwärtig ausgewählten Anweisung eine Nichtübereinstimmung erfasst wird (512), dann wird eine Nachricht erzeugt (514), die die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung aufgetreten ist. Der Verifizierer wird dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (516).
Wenn die gegenwärtig ausgewählte Anweisung keine Daten aus einer lokalen Variable liest (510) oder der Datentyp-Vergleich im Schritt 512 zu einer Übereinstimmung führt, dann setzt der Verifizierer die Verarbeitung der gegenwärtig ausgewählten Anweisung im Schritt 520 fort.
Falls in 4G die gegenwärtig ausgewählte Anweisung die Daten in einer lokalen Variable speichert (520), wird die entsprechende virtuelle lokale Variable kontrolliert (522), um zu bestimmen, ob sie einen Datentypwert speichert. Falls die virtuelle lokale Variable einen Datentypwert speichert (wodurch angezeigt wird, dass in der lokalen Variable vorausgehend Daten gespeichert worden sind), vergleicht der Verifizierer die Datentyp-Informationen in der virtuellen lokalen Variable mit dem Datentyp, der der gegenwärtig ausgewählten Bytecode-Anweisung zugeordnet ist (524). Wenn eine Nichtübereinstimmung zwischen den in der virtuellen lokalen Variable gespeicherten Datentyp-Informationen und den Datentyp-Anforderungen der gegenwärtig ausgewählten Anweisung erfasst wird (524), dann wird eine Nachricht erzeugt (526), die die Stelle im Bytecode-Programm kennzeichnet, wo die Nichtübereinstimmung aufgetreten ist. Der Verifizierer wird dann einen Verifikationsstatuswert 245 für das Programm auf falsch setzen und den Verifikationsprozess abbrechen (528).
Falls die gegenwärtig ausgewählte Anweisung keine Daten in einer lokalen Variable speichert (520), ist die Verarbeitung für die gegenwärtig ausgewählte Anweisung abgeschlossen. Wenn die gegenwärtig ausgewählte Anweisung Daten in einer lokalen Variable speichert, die virtuelle lokale Variable aber keinen Datentypwert speichert (wodurch anzeigt wird, dass keine Anweisung, die Daten in der lokalen Variable speichern würde, durch den Verifizierer bis jetzt verarbeitet worden ist), dann wird der der ausgewählten Bytecode-Anweisung zugeordnete Datentyp in der virtuellen lokalen Variable gespeichert (Schritt 530).
Als Nächstes überprüft der Verifizierer (540), um festzustellen, ob dies die letzte Anweisung im zu verarbeitenden Bytecode-Programm 340 ist. Wenn noch weitere zu verarbeitende Anweisungen bleiben, dann lädt (542) der Verifizierer die nächste Anweisung und wiederholt, beginnend im Schritt 432, den Verifikationsprozess. Falls keine weiteren Anweisungen zu verarbeiten sind, wird dann der Verifizierer einen Verifikationsstatuswert 245 für das Programm auf wahr setzen (544), wodurch der Abschluss des Verifikationsprozesses signalisiert wird.
Der Bytecode-Interpreter
Unter Bezugnahme auf den Ablaufplan in 5 und den Anhang 2 wird nun die Ausführung des Bytecode-Interpreters 242 beschrieben. Der Anhang 2 listet eine Pseudocode-Darstellung des Bytecode-Interpreters auf.
Nachdem ein spezifiziertes Bytecode-Programm als ein auszuführendes Programm empfangen oder anders ausgewählt worden ist (560), ruft (562) der Bytecode-Programm-Interpreter 242 den Bytecode-Verifizierer 240 auf, um die Integrität des spezifizierten Bytecode-Programms zu verifizieren. Der Bytecode-Verifizierer ist oben beschrieben.
Falls der Verifizierer einen "Verifikationsfehler"-Wert zurückschickt (564), wird der Versuch, das spezifizierte Bytecode-Programm auszuführen, durch den Interpreter abgebrochen (566).
Falls der Verifizierer 242 einen "Verifikationserfolgs"-Wert zurückschickt (564), wird das spezifizierte Bytecode-Programm mit den Betriebsmittel-Dienstprogrammen und irgendwelchen anderen Programmen, Funktionen und Objekten, auf die durch das Programm Bezug genommen werden kann, gebunden (568). Ein derartiger Schritt des Bindens ist ein herkömmlicher Schritt vor der Ausführung in vielen Programminterpretern. Dann wird das gebundene Bytecode-Programm durch den Interpreter interpretiert und ausgeführt (570). Der Bytecode-Interpreter der vorliegenden Erfindung führt keine Operandenstapelüberlauf- und Operandenstapelunterlauf-Prüfungen während der Programmausführung aus, wobei er außerdem während der Programmausführung keine Datentyp-Prüfung für die im Operandenstapel gespeicherten Daten ausführt. Diese herkömmlichen Stapelüberlauf-, Stapelunterlauf- und Datentyp-Prüfungsoperationen können durch die vorliegende Erfindung übersprungen werden, weil der Interpret bereits verifiziert hat, dass Fehlern dieses Typs während der Programmausführung nicht begegnet wird.
Der Programminterpreter der vorliegenden Erfindung ist für die Ausführung von Bytecode-Programmen besonders effizient, die Laufanweisungsschleifen besitzen, die mehrmals ausgeführt werden, weil die Operandenstapel-Prüferanweisungen nur einmal für jeden Bytecode in jeder derartigen Laufanweisungsschleife in der vorliegenden Erfindung ausgeführt werden. Im Gegensatz muss der Interpreter während der Ausführung eines Programms durch einen Vereinbarungs-Interpreter den Operandenstapel kontinuierlich nach Überläufen (d. h. dem Hinzufügen von mehr Daten zum Stapel als der Stapel speichern kann) und Unterläufen (d. h. den Versuchen, Daten aus dem Stapel ausspeichern, wenn der Stapel leer ist) überwachen. Eine derartige Überwachung muss normalerweise für alle Anweisungen ausgeführt werden, die den Stapelstatus ändern (das meistens alle Anweisungen einschließt). Für viele Programme sind die durch den Interpreter ausgeführten Anweisungen zur Überwachung des Stapels für etwa 80% der Ausführungszeit eines interpretierten berechneten Programms verantwortlich. Im Ergebnis wird der Interpreter der vorliegenden Erfindung oft Programme beim zwei- bis fünffachen der Geschwindigkeit eines herkömmlichen Programminterpreters ausführen, der auf dem gleichen Computer läuft.

Die vorangehenden Beschreibungen der spezifischen Ausführungsformen der vorliegenden Erfindung sind für die Zwecke der Veranschaulichung und Beschreibung dargestellt worden. Sie sind nicht als erschöpfend oder um die Erfindung auf die offenbarten genauen Formen einzuschränken beabsichtigt, wobei offensichtlich viele Modifikationen und Variationen im Licht der obige Lehren möglich sind. Die Ausführungsformen wurden gewählt und beschrieben, um die Prinzipien der Erfindung und ihrer praktischen Anwendung am besten zu erklären, um dadurch anderen Fachleuten zu ermöglichen, die Erfindung und verschiedene Ausführungsformen mit zahlreichen Modifikationen am besten zu verwenden, wie sie für die beabsichtigte spezielle Verwendung geeignet sind. Es ist beabsichtigt, dass der Umfang der Erfindung durch die beigefügten Ansprüche und ihre Äquivalente definiert ist. TABELLE 1 DIE BYTECODES IN DER OAK-SPRACHE

NAME DER ANWEISUNG	KURZBESCHREIBUNG
aaload	lade Bezugnahme auf Objekt aus Feld
aastore	speichere Bezugnahme auf Objekt in Feld für Bezugnahmen auf Objekt
aconst_null	speichere Null-Objekt ein
aload	lade lokale Objektvariable
areturn	schicke Bezugnahme auf Objekt aus Funktion zurück
arraylength	erhalte Feldlänge
astore	speichere Bezugnahme auf Objekt in lokaler Variable
astore_<n>	speichere Bezugnahme auf Objekt in lokaler Variable
athrow	Throw-Ausnahme
bipush	speichere vorzeichenbehaftete ganze Ein-Byte-Zahl ein
breakpoint	rufe Unterbrechungspunkt-Behandlungseinrichtung auf
catchsetup	konfiguriere Ausnahme-Behandlungseinrichtung
catchteardown	setze Ausnahme-Behandlungseinrichtung zurück
checkcast	stelle sicher, dass Objekt von einem gegebenen Typ ist
df2	setze Gleitkommazahl mit doppelter Genauigkeit in Gleitkommazahl mit einfacher Genauigkeit um
d2i	setze Gleitkommazahl mit doppelter Genauigkeit in ganze Zahl um
d2l	setze Gleitkommazahl mit doppelter Genauigkeit in lange ganze Zahl um
dadd	addiere Gleitkommazahlen mit doppelter Genauigkeit
daload	lade Gleitkommazahl mit doppelter Genauigkeit aus Feld
dastore	speichere Gleitkommazahl mit doppelter Genauigkeit in Feld
dcmpg	vergleiche zwei Gleitkommazahlen mit doppelter Genauigkeit (schicke 1 zurück, wenn nicht zu vergleichen)
dcmpl	vergleiche zwei Gleitkommazahlen mit doppelter Genauigkeit (schicke –1 zurück, wenn nicht zu vergleichen)
dconst_<d>	speichere Gleitkommazahl mit doppelter Genauigkeit ein
ddiv	teile Gleitkommazahlen mit doppelter Genauigkeit

dload	lade Gleitkommazahl mit doppelter Genauigkeit aus lokaler Variable
dload_<n>	lade Gleitkommazahl mit doppelter Genauigkeit aus lokaler Variable
dmod	führe Modulo-Funktion an Gleitkommazahlen mit doppelter Genauigkeit aus
dmul	multipliziere Gleitkommazahlen mit doppelter Genauigkeit
dneg	negiere Gleitkommazahl mit doppelter Genauigkeit
dreturn	schicke Gleitkommazahl mit doppelter Genauigkeit aus Funktion zurück
dstore	speichere Gleitkommazahl mit doppelter Genauigkeit in lokaler Variable
dstore_<n>	speichere Gleitkommazahl mit doppelter Genauigkeit in lokaler Variable
dsub	subtrahiere Gleitkommazahlen mit doppelter Genauigkeit
dup	verdopple oberstes Stapelwort
dup2	verdopple die obersten zwei Stapelwörter
dup2_x1	verdopple die obersten zwei Stapelwörter und setze zwei herunter
dup2_x2	verdopple die obersten zwei Stapelwörter und setze drei herunter
dup_x1	verdopple das oberste Stapelwort und setze zwei herunter
dup_x2	verdopple das oberste Stapelwort und setze drei herunter
f2d	setze Gleitkommazahl mit einfacher Genauigkeit in Gleitkommazahl mit doppelter Genauigkeit um
f2i	setze Gleitkommazahl mit einfacher Genauigkeit in ganze Zahl um
f2l	setze Gleitkommazahl mit einfacher Genauigkeit in lange ganze Zahl um
fadd	addiere Gleitkommazahlen mit einfacher Genauigkeit
faload	lade Gleitkommazahl mit einfacher Genauigkeit aus Feld
fastore	speichere in Feld für Gleitkommazahl mit einfacher Genauigkeit
fempg	vergleiche Gleitkommazahlen mit einfacher Genauigkeit (schicke 1 zurück, wenn nicht zu vergleichen)

fempl	vergleiche Gleitkommazahlen mit einfacher Genauigkeit (schicke –1 zurück, wenn nicht zu vergleichen)
fconst_<f>	speichere Gleitkommazahl mit einfacher Genauigkeit ein
fdiv	teile Gleitkommazahlen mit einfacher Genauigkeit
fload	lade Gleitkommazahl mit einfacher Genauigkeit aus lokaler Variable
fload_<n>	lade Gleitkommazahl mit einfacher Genauigkeit aus lokaler Variable
fmod	führe Modulo-Funktion an Gleitkommazahlen mit einfacher Genauigkeit aus
fmul	multipliziere Gleitkommazahlen mit einfacher Genauigkeit
fneg	negiere Gleitkommazahl mit einfacher Genauigkeit
freturn	schicke Gleitkommazahl mit einfacher Genauigkeit aus Funktion zurück
fstore	speichere Gleitkommazahl mit einfacher Genauigkeit in lokaler Variable
fstore_<n>	speichere Gleitkommazahl mit einfacher Genauigkeit in lokaler Variable
fsub	subtrahiere Gleitkommazahlen mit einfacher Genauigkeit
getfield	rufe Feld aus Objekt ab
getstatic	setze statisches Feld aus Klasse
goto	verzweige immer
i2d	setze ganze Zahl in Gleitkommazahl mit doppelter Genauigkeit um
i2f	setze ganze Zahl in Gleitkommazahl mit einfacher Genauigkeit um
i2l	setze ganze Zahl in lange ganze Zahl um
ladd	addiere ganze Zahlen
iaload	lade ganze Zahl aus Feld
iand	boolesches UND für zwei ganze Zahlen
iastore	speichere in ganzzahligem Feld
iconst_<n>	speichere ganze Zahl ein
iconst_m1	speichere ganzzahlige Konstante minus 1 ein
idiv	ganzzahlige Division
if_acmpeq	verzweige, falls Objekte gleich sind
if_acmpne	verzweige, falls Objekte nicht gleich sind

if_icmpeq	verzweige, falls ganze Zahlen gleich sind
if_icmpge	verzweige, falls ganze Zahl größer als oder gleich ist
if_icmpgt	verzweige, falls ganze Zahl größer als ist
if_icmple	verzweige, falls ganze Zahl kleiner als oder gleich ist
if_icmplt	verzweige, falls ganze Zahl kleiner als ist
if_icmpne	verzweige, falls ganze Zahlen nicht gleich sind
ifeq	verzweige, falls gleich 0
ifge	verzweige, falls größer als oder gleich 0
ifgt	verzweige, falls größer als 0
ifle	verzweige, falls kleiner als oder gleich 0
iflt	verzweige, falls kleiner als 0
ifne	verzweige, falls nicht gleich 0
iinc	inkrementiere lokale Variable um Konstante
iload	lade ganze Zahl aus lokaler Variable
iload_<n>	lade ganze Zahl aus lokaler Variable
imod	führe Modulo-Funktion an ganzen Zahlen aus
imul	multipliziere ganze Zahlen
ineg	negiere ganze Zahl
instanceof	bestimme, ob Objekt vom gegebenen Typ ist
int2byte	setze ganze Zahl in vorzeichenbehaftetes Byte um
int2char	setze ganze Zahl in Zeichen um
invokeinterface	rufe Schnittstellenverfahren auf
invokemethod	rufe Klassenverfahren auf
invokesuper	rufe Super-Klassenverfahren auf
ior	boolesches ODER für zwei ganze Zahlen
ireturn	schicke ganze Zahl aus Funktion zurück
ishl	verschiebe ganz Zahl nach links
ishr	verschiebe nach rechts für ganzzahlige Arithmetik
istore	speichere ganze Zahl in lokaler Variable vindex
istore_<n>	speichere ganze Zahl in lokaler Variable n
isub	subtrahiere ganze Zahlen
iushr	verschiebe ganze Zahl logisch nach rechts
ixor	boolesches EXKLUSIV-ODER für zwei ganze Zahlen
jsr	springe zu Unterprogramm
12d	setze lange ganze Zahl in Gleitkommazahl mit doppelter Genauigkeit um

12f	setze lange ganze Zahl in Gleitkommazahl mit einfacher Genauigkeit um
12i	setze lange ganze Zahl in ganze Zahl um
ladd	addiere lange ganze Zahlen
laload	lade lange ganze Zahl aus Feld
land	boolesches UND für zwei lange ganze Zahlen
lastore	speichere in Feld für lange ganze Zahlen
lcmp	vergleiche lange ganze Zahlen
lconst_<l>	speichere lange ganzzahlige Konstante ein
ldc1	speichere Element aus konstanter Datenbasis ein
ldc2	speichere Element aus konstanter Datenbasis ein
ldc2w	speichere lange ganze Zahl oder Gleitkommazahl mit doppelter Genauigkeit aus konstanter Datenbasis ein
ldiv	teile lange ganze Zahlen
lload	lade lange ganze Zahl aus lokaler Variable
lload_<n>	lade lange ganze Zahl aus lokaler Variable
lmod	führe Modulo-Funktion an langen ganzen Zahlen aus
lmul	multipliziere lange ganze Zahlen
lneg	negiere lange ganze Zahl
lookupswitch	greife bei Tastenübereinstimmung auf Sprungtabelle zu und springe
lor	boolesches ODER für zwei lange ganze Zahlen
lreturn	schicke lange ganze Zahl aus Funktion zurück
lshl	verschiebe lange ganze Zahl nach links
lshr	verschiebe für Arithmetik für lange ganze Zahlen nach rechts
lstore	speichere lange ganze Zahl in lokaler Variable
lstore_<n>	speichere lange ganze Zahl in lokaler Variable
lsub	subtrahiere lange ganze Zahlen
lushr	verschiebe lange ganze Zahl logisch nach rechts
lxor	boolesches EXKLUSIV-ODER für lange ganze Zahlen
monitorenter	trete in überwachten Bereich des Codes ein
monitorexit	verlasse den überwachten Bereich des Codes
new	erzeuge neues Objekt
newarray	weise neues Feld zu
newfromname	erzeuge neues Objekt aus Namen

nop	tue nichts
pop	speichere oberstes Stapelwort aus
pop2	speichere obersten zwei Stapelwörter aus
putfield	setze Feld in Objekt
putstatic	setze statisches Feld in Klasse
ret	Rücksprung aus Unterprogramm
return	Rücksprung (leer) aus Prozedur
saload	lade vorzeichenbehaftetes Byte aus Feld
sastore	speichere in vorzeichenbehaftetes Byte-Feld
siaload	lade vorzeichenlose kurze ganze Zahl aus Feld
siastore	speichere in vorzeichenloses kurzes Feld
sipush	speichere vorzeichenbehaftete ganze Zwei-Byte-Zahl ein
tableswitch	greife durch Index auf Sprungtabelle zu und springe
verifystack	verifiziere, ob Stapel leer

ANHANG 1 Der Pseudocode für den OAK-Bytecode-Verfizierer
ANHANG 2 Der Pseudocode für den Bytecode-Interpreter

Claims

Computerimplementiertes Verfahren, wobei die Schritte des Verfahrens umfassen: Bereitstellen eines Programms (221, 340), das aus stapelorientiertem Low-Level-Programmcode gebildet ist; gekennzeichnet durch: Verifizieren vor der Ausführung, dass, wenn ein Befehl des Programms (221, 340) ausgeführt wird, der auf mehr als einem Ausführungspfad ausgeführt werden kann, eine Anzahl von Operanden in einem Stapel bei Erreichen dieses Befehls während der Ausführung unabhängig von dem gewählten Ausführungspfad zum Erreichen des Befehls gleich ist und ein Typzustand des Stapels bei Erreichen dieses Befehls während der Ausführung auf einem ersten Ausführungspfad, der den Befehl enthält, mit einem Typzustand des Stapels bei Erreichen dieses Befehls während der Ausführung auf allen anderen Ausführungspfaden, die den Befehl enthalten, kompatibel ist; und Ausführen des verifizierten Programms (221, 340).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Bereitstellungsschritt das wahlweise Verbinden eines Computersystems (102, 202) über ein Netz (120, 220) mit einem sendenden Computer (104, 204) umfasst, um von dem sendenden Computer (104, 204) das Programm (221, 340) zu empfangen.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Verifikationsschritt umfasst, vor der Ausführung des Programms (221, 340) zu bestätigen, dass die Anzahl von Operanden in dem Stapel bei Erreichen des Befehls, der auf mehr als einem Ausführungspfad ausgeführt werden kann, für alle Ausführungspfade, die den Befehl enthalten, gleich ist, selbst wenn der Stapel vor der Ausführung des Befehls nicht leer ist.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Verifikationsschritt umfasst, vor der Ausführung des Programms zu bestätigen, dass die Ausführung irgendeiner Schleife in dem Programm keine Nettohinzufügung oder -löschung von Operanden in dem Stapel zur Folge hat.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der Ausführungsschritt das Ausführen des verifizierten Programms ohne Prüfen eines Überlaufs oder Unterlaufs des Stapels umfasst.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Verifikationsschritt umfasst, vor der Ausführung zu verifizieren, dass dann, wenn eine Schleife des Programms (221, 340) ausgeführt wird, unmittelbar vor und nach jeder Iteration der Schleife eine Anzahl von Operanden in dem Stapel gleich ist, selbst wenn der Stapel nicht leer ist, und dass ein Typzustand des Stapels mit einem anfänglichen Typzustand des Stapels unabhängig davon, wie oft die Schleife ausgeführt wird, kompatibel bleibt.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Ausführungsschritt umfasst, das Programm (221, 340) ohne Vornehmen einer Prüfung während der Ausführung des Programms, die einer durch die Verifikation vorgenommenen Prüfung entspricht, auszuführen.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass jeder Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst und die Verifikation die Bestimmung umfasst, ob die Ausführung irgendeines bytecodierten Befehls in dem Programm (221, 340) vorgegebene Datentyp-Beschränkungen für diesen Befehl verletzen würde.
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass wenigstens ein Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst, die eine Operation an einem spezifischen Datentyp repräsentiert und aus der Gruppe gewählt ist, die besteht aus: aaload, aastore, aconst_null, aload, areturn, arraylength, astore, astore_<n>, athrow, bipush, breakpoint, catchsetup, catchteardown, checkcast, df2, d2i, d2l, dadd, daload, dastore, dcmpg, dcmpl, dconst_<d>, ddiv, dload, dload_<d>, dmod, dmul, dneg, dreturn, dstore, dstore_<n>, dsub, dup, dup2, dup2_x1, dup2_x2, dup_x1, dup_-x2, f2d, f2i, f2l, fadd, faload, fastore, fempg, fempl, fconst_<f>, fdiv, fload, fload_<n>, fmod, fmul, fneg, freturn, fstore, fstore_<n>, fsub, gatfield, getstatic, goto, i2d, i2f, i2l, iadd, iaload, iand, iastore, iconst_<n>, iconst_m1, idiv, if_acmpeq, if_acmpne, if_icmpeq, if_icmpge, if_icmpgt, if_icmple, if_icmplt, if_icmpne, ifeq, ifge, ifgt, ifle, iflt, ifne, iinc, iload, iload_<n>, imod, imul, ineg, instanceof, int2byte, int2char, invokeinterface, invokemethod, invokesuper, ior, ireturn, ishl, lshr, istore, istore_<n>, isub, iushr, ixor, jsr, 12d, 12f, 12i, ladd, laload, land, lastore, lcmp, lconst_<l>, ldc1, ldc2, ldc2w, ldiv, lload, lload_<n>, lmod, lmul, lneg, lookupswitch, lor, lreturn, lshl, lshr, lstore, lstore_<n>, lsub, lushr, lxor, monitorenter, monitorexit, new, newarray, newfromname, nop, pop, pop2, putfield, putstatic, ret, return, saload, sastore, siaload, siastore, sipush, tableswitch, und verifystack.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der Verifikationsschritt umfasst zu zertifizieren, dass das Programm (221, 340) eine Stapel-Nichtüberlaufbeschränkung und eine Stapel-Nichtunterlaufbeschränkung erfüllt.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Verifikationsschritt das Verwenden eines virtuellen Stapels (344) zum Verfolgen des Typzustands des Stapels umfasst.
Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass der Verifikationsschritt die Verwendung einer Anordnung virtueller lokaler Variablen (345) zum Verfolgen eines Typzustands lokaler Variablen, die von dem Programm (221, 340) verwendet werden, umfasst.
Computersystem, das umfasst: Speicher (210, 212) zum Speichern eines Programms (221, 340), das aus stapelorientiertem Low-Level-Programmcode gebildet ist; eine Datenverarbeitungseinheit (206) zum Ausführen von Programmen, die in dem Speicher (210, 212) gespeichert sind; gekennzeichnet durch: einen Programmverifizierer (240), der in dem Speicher (210, 212) gespeichert ist und von der Datenverarbeitungseinheit (206) ausgeführt wird, wobei der Programmverifizierer (240) Befehle umfasst, um vor der Ausführung zu verifizieren, dass dann, wenn ein Befehl des Programms (221, 340) ausgeführt wird, der auf mehr als einem Ausführungspfad ausgeführt werden kann, eine Anzahl von Operanden in einem Stapel bei Erreichen des Befehls während der Ausführung unabhängig von dem verwendeten Ausführungspfad zum Erreichen des Befehls gleich ist und ein Typzustand des Stapels bei Erreichen des Befehls während der Ausführung eines ersten Ausführungspfads, der den Befehl enthält, mit einem Typzustand des Stapels bei Erreichen des Befehls während der Ausführung auf allen anderen Ausführungspfaden, die den Befehl enthalten, kompatibel ist; und ein Programmausführungsmodul (242) zum Ausführen des verifizierten Programms (221, 340).
Computersystem nach Anspruch 13, gekennzeichnet durch Mittel zum wahlweisen Verbinden des Computersystems (102, 202) über ein Netz (120, 220) mit einem sendenden Computer (104, 204), um von dem sendenden Computer (104, 204) das Programm (221, 340) zu empfangen.
Computersystem nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle umfassen, um vor der Ausführung des Programms (221, 340) zu bestätigen, dass die Anzahl von Operanden in dem Stapel bei Erreichen des Befehls, der auf mehr als einem Ausführungspfad ausgeführt werden kann, für alle Ausführungspfade, die den Befehl enthalten, selbst dann, wenn der Stapel vor der Ausführung des Befehls nicht leer ist, gleich ist.
Computersystem nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle enthalten, um vor der Ausführung des Programms (221, 340) zu bestätigen, dass die Ausführung irgendeiner Schleife in dem Programm keine Nettohinzufügung oder -löschung von Operanden in dem Stapel zur Folge hat.
Computersystem nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, dass das Programmausführungsmodul (242) nicht auf einen Überlauf oder einem Unterlauf des Stapels prüft, wenn das verifizierte Programm (221, 340) ausgeführt wird.
Computersystem nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle umfassen, um vor der Ausführung zu verifizieren, dass, wenn eine Schleife des Programms (221, 340) ausgeführt wird, unmittelbar vor und nach jeder Iteration der Schleife die Anzahl von Operanden in dem Stapel gleich ist, selbst wenn der Stapel nicht leer ist, und dass ein Typzustand des Stapels mit einem anfänglichen Typzustand des Stapels unabhängig davon, wie oft die Schleife ausgeführt wird, kompatibel bleibt.
Computersystem nach einem der Ansprüche 13 bis 18, dadurch gekennzeichnet, dass das Programmausführungsmodul (242) Befehle zum Ausführen des Programms (221, 340) ohne Vornehmen einer Prüfung während der Ausführung des Programms (221, 340), die einer von dem Programmverifizierer (240) vorgenommenen Prüfung entspricht, umfasst.
Computersystem nach einem der Ansprüche 13 bis 19, dadurch gekennzeichnet, dass jeder Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst und dass der Programmverifizierer (240) Befehle umfasst, um zu bestimmen, ob die Ausführung irgendeines bytecodierten Befehls in dem Programm (221, 340) vorgegebene Datentypbeschränkungen für diesen Befehl verletzen würde.
Computersystem nach einem der Ansprüche 13 bis 20, dadurch gekennzeichnet, dass wenigstens ein Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst, die eine Operation an einem bestimmten Datentyp repräsentieren und aus der Gruppe gewählt sind, die besteht aus: aaload, aastore, aconst_null, aload, areturn, arraylength, astore, astore_<n>, athrow, bipush, breakpoint, catchsetup, catchteardown, checkcast, df2, d2i, d2l, dadd, daload, dastore, dcmpg, dcmpl, dconst_<d>, ddiv, dload, dload_<d>, dmod, dmul, dneg, dreturn, dstore, dstore_<n>, dsub, dup, dup2, dup2_x1, dup2_x2, dup_x1, dup_-x2, f2d, f2i, f2l, fadd, faload, fastore, fempg, fempl, fconst_<f>, fdiv, fload, fload_<n>, fmod, fmul, fneg, freturn, fstore, fstore_<n>, fsub, gatfield, getstatic, goto, i2d, i2f, i2l, iadd, iaload, iand, iastore, iconst_<n>, iconst_m1, idiv, if_acmpeq, if_acmpne, if_icmpeq, if_icmpge, if_icmpgt, if_icmple, if_icmplt, if_icmpne, ifeq, ifge, ifgt, ifle, iflt, ifne, iinc, iload, iload_<n>, imod, imul, ineg, instanceof, int2byte, int2char, invokeinterface, invokemethod, invokesuper, ior, ireturn, ishl, lshr, istore, istore_<n>, isub, iushr, ixor, jsr, 12d, 12f, 12i, ladd, laload, land, lastore, lcmp, lconst_<l>, ldc1, ldc2, ldc2w, ldiv, lload, lload_<n>, lmod, lmul, lneg, lookupswitch, lor, lreturn, lshl, lshr, lstore, lstore_<n>, lsub, lushr, lxor, monitorenter, monitorexit, new, newarray, newfromname, nop, pop, pop2, putfield, putstatic, ret, return, saload, sastore, siaload, siastore, sipush, tableswitch, und verifystack,
Computersystem nach einem der Ansprüche 13 bis 21, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, um zu zertifizieren, dass das Programm (221, 340) eine Stapel-Nichtüberlaufbeschränkung und eine Stapel-Nichtunterlaufbeschränkung erfüllt.
Computersystem nach einem der Ansprüche 13 bis 22, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, die einen virtuellen Stapel (344) verwenden, um den Typzustand des Stapels zu verfolgen.
Computersystem nach einem der Ansprüche 13 bis 23, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, die eine Anordnung virtueller lokaler Variablen (345) verwenden, um einen Typzustand lokaler Variablen, die von dem Programm (221, 340) verwendet werden, zu verfolgen.
Computerprogrammprodukt für die Verwendung in Verbindung mit einem Computersystem (102, 202), wobei das Computerprogrammprodukt ein computerlesbares Speichermedium und einen darin eingebetteten Computerprogrammmechanismus enthält, wobei der Computerprogrammmechanismus umfasst: einen Programmverifizierer (240) zum Analysieren eines Programms (221, 340), das aus stapelorientiertem Low-Level-Programmcode gebildet ist; und ein Programmausführungsmodul (242) zum Ausführen des verifizierten Programms; dadurch gekennzeichnet, dass: der Programmverifizierer (240) Befehle umfasst, um vor der Ausführung des Programms (221, 340) zu verifizieren, dass, wenn ein Befehl des Programms (221, 340) ausgeführt wird, der auf mehr als einem Ausführungspfad ausgeführt werden kann, eine Anzahl von Operanden in dem Stapel bei Erreichen des Befehls während der Ausführung unabhängig von dem genommenen Ausführungspfad zum Erreichen des Befehls gleich ist und ein Typzustand des Stapels bei Erreichen des Befehls während der Ausführung eines ersten Ausführungspfads, der den Befehl enthält, mit einem Typzustand des Stapels bei Erreichen des Befehls während der Ausführung auf allen anderen Ausführungspfaden, die den Befehl enthalten, kompatibel ist.
Computerprogrammprodukt nach Anspruch 25, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle umfassen, um vor der Ausführung des Programms (221, 340) zu bestätigen, dass die Anzahl von Operanden in dem Stapel bei Erreichen des Befehls, der auf mehr als einem Ausführungspfad ausgeführt werden kann, für alle Ausführungspfade, die den Befehl enthalten, selbst dann, wenn der Stapel vor der Ausführung des Befehls nicht leer ist, gleich ist.
Computerprogrammprodukt nach Anspruch 25 oder 26, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle enthalten, um vor der Ausführung des Programms (221, 340) zu bestätigen, dass die Ausführung irgendeiner Schleife in dem Programm (221, 340) keine Nettohinzufügung oder -löschung von Operanden in dem Stapel zur Folge hat.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 27, dadurch gekennzeichnet, dass das Programmausführungsmodul (242) nicht auf einen Überlauf und einen Unterlauf des Stapels prüft, wenn das verifizierte Programm (221, 340) ausgeführt wird.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 28, dadurch gekennzeichnet, dass die Verifikationsbefehle Befehle umfassen, um vor der Ausführung zu verifizieren, dass dann, wenn eine Schleife des Programms (221, 340) ausgeführt wird, unmittelbar vor und nach jeder Iteration der Schleife eine Anzahl von Operanden in dem Stapel gleich ist, selbst wenn der Stapel nicht leer ist, und ein Typ, der jedem der Operanden in dem Stapel zugeordnet ist, unabhängig davon, wie oft die Schleife ausgeführt wird, kompatibel bleibt.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 29, dadurch gekennzeichnet, dass das Programmausführungsmodul (242) Befehle umfasst, um das Programm (221, 340) auszuführen, ohne eine Prüfung während der Ausführung des Programms (221, 340) vorzunehmen, die einer Prüfung entspricht, die von dem Programmverifizierer (240) vorgenommen wird.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 30, dadurch gekennzeichnet, dass jeder Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst und dass der Programmverifizierer (240) Befehle umfasst, um zu bestimmen, ob die Ausführung irgendeines bytecodierten Befehls des Programms (221, 340) vorgegebene Datentypbeschränkungen für diesen Befehl verletzen würde.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 31, dadurch gekennzeichnet, dass wenigstens ein Befehl des Programms (221, 340) einen oder mehrere Bytecodes umfasst, die eine Operation an einem bestimmten Datentyp repräsentieren und aus der Gruppe gewählt sind die besteht aus: aaload, aastore, aconst_null, aload, areturn, arraylength, astore, astore_<n>, athrow, bipush, breakpoint, catchsetup, catchteardown, checkcast, df2, d2i, d2l, dadd, daload, dastore, dcmpg, dcmpl, dconst_<d>, ddiv, dload, dload_<d>, dmod, dmul, dneg, dreturn, dstore, dstore_<n>, dsub, dup, dup2, dup2_x1, dup2_x2, dup_x1, dup_-x2, f2d, f2i, f2l, fadd, faload, fastore, fempg, fempl, fconst_<f>, fdiv, fload, fload_<n>, fmod, fmul, fneg, freturn, fstore, fstore_<n>, fsub, gatfield, getstatic, goto, i2d, i2f, i2l, iadd, iaload, iand, iastore, iconst_<n>, iconst_m1, idiv, if_acmpeq, if_acmpne, if_icmpeq, if_icmpge, if_icmpgt, if_icmple, if_icmplt, if_icmpne, ifeq, ifge, ifgt, ifle, iflt, ifne, iinc, iload, iload_<n>, imod, imul, ineg, instanceof, int2byte, int2char, invokeinterface, invokemethod, invokesuper, ior, ireturn, ishl, lshr, istore, istore_<n>, isub, iushr, ixor, jsr, 12d, 12f, 12i, ladd, laload, land, lastore, lcmp, lconst_<l>, ldc1, ldc2, ldc2w, ldiv, lload, lload_<n>, lmod, lmul, lneg, lookupswitch, lor, lreturn, lshl, lshr, lstore, lstore_<n>, lsub, lushr, lxor, monitorenter, monitorexit, new, newarray, newfromname, nop, pop, pop2, putfield, putstatic, ret, return, saload, sastore, siaload, siastore, sipush, tableswitch, und verifystack.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 32, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, um zu zertifizieren, dass das Programm (221, 340) eine Stapel-Nichtüberlaufbeschränkung und eine Stapel-Nichtunterlaufbeschränkung erfüllt.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 33, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, die einen virtuellen Stapel (344) verwenden, um den Typzustand des Stapels zu verfolgen.
Computerprogrammprodukt nach einem der Ansprüche 25 bis 34, dadurch gekennzeichnet, dass der Programmverifizierer (240) Befehle umfasst, die eine Anordnung virtueller lokaler Variablen (345) verwenden, um einen Typzustand lokaler Variablen, die von dem Programm (221, 340) verwendet werden, zu verfolgen.