-
Auf
das folgende gekennzeichnete US-Patent wird in dieser Anmeldung
Bezug genommen:
US-Patent Nr. 5966542 mit dem Titel "METHOD AND SYSTEM
FOR LOADING CLASSES IN READ-ONLY MEMORY", angemeldet am 10. August 1998.
-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft allgemein Datenverarbeitungssysteme
und insbesondere plattformunabhängige
selektive Im-Voraus-Kompilierung.
-
HINTERGRUND
UND INFORMATION ZUM THEMA
-
In
der heutigen Gesellschaft ist das Internet zu einem wichtigen Medium
für den
Informationsaustausch geworden. Obwohl das Internet jetzt in der Öffentlichkeit
sehr populär
ist, begann es anfangs als ein System (oder Netzwerk) untereinander
verbundener Rechner, die von der Regierung und Akademikern verwendet
wurden. Ein frühes
Problem dieses Netzwerks entsprang aus der Tatsache, daß die untereinander
verbundenen Rechner nicht gleich waren; sie verwendeten unterschiedliche
Hardware sowie unterschiedliche Betriebssysteme. Der Informationsaustausch
in so einem heterogenen Netzwerk warf ein Kommunikationsproblem
auf. Dieses Problem wurde durch eine Vereinbarung über gemeinsame
Standards gelöst,
einschließlich
Protokollen wie etwa Übertragungssteuerungsprotokoll/Internetprotokoll
(TCP/IP) und Hypertext-Übermittlungsprotokoll (HTTP).
Diese Protokolle befähigten
verschiedenartige untereinander verbundene Maschinen, Information
in Form statischen Texts oder grafischer Dokumente gemeinsam zu
nutzen.
-
Diese
Protokolle stellten jedoch nur zwei Schritte in der Entwicklung
des Internets dar. Obwohl die Benutzer Informationsdokumente zwischen
verschiedenartigen mit dem Internet verbundenen Rechnern austauschen
können,
können
sie keine ausführbaren
Anwendungsprogramme austauschen, die in herkömmlichen Sprachen wie etwa
C oder C++ geschrieben sind, die dafür konzipiert sind, eine Verbindung
mit einem bestimmten Prozessor (zum Beispiel dem Intel-PentiumTM-Prozessor) und/oder einem bestimmten Betriebssystem
(zum Beispiel Windows 97TM oder DOS) herzustellen.
Dieses Problem wurde mit Erscheinen der Programmiersprache JavaTM und ihres zugehörigen Laufzeitsystems gelöst.
-
Java
ist eine objektorientierte Programmiersprache, die zum Beispiel
in einem Text mit dem Titel "The
JavaTM Tutorial" von Mary Campione und Kathy Walrath,
Addison-Wesley, 1996 beschrieben wird. Wichtig ist, daß Java eine
interpretierte Sprache ist, die plattformunabhängig ist, das heißt, ihr
Nutzen ist nicht auf ein bestimmtes Rechnersystem begrenzt. Unter
Verwendung der Java-Programmiersprache schreibt ein Softwareentwickler
Programme in einer Form, die im allgemeinen als Java-Quellcode bezeichnet
wird. Wenn der Entwickler die Entwicklung des Softwareprogramms
vervollständigt,
kompiliert er es dann mit einem Java-Compiler in eine als Bytecode
bezeichnete Zwischenform. Sowohl der Java-Quellcode als auch der Bytecode sind
plattformunabhängig.
-
Der
kompilierte Bytecode kann dann auf irgendeinem Rechnersystem ausgeführt werden,
das ein kompatibles Laufzeitsystem verwendet, das eine virtuelle
Maschine (VM) aufweist, wie etwa die in dem Text mit dem Titel "The Java Virtual
Machine Specification",
durch Tim Lindholm und Frank Yellin, Addison-Wesley, 1996 beschriebene
virtuelle Java-Maschine. Die Java-VM fungiert als Interpreter zwischen dem
Bytecode und dem bestimmten verwendeten Rechnersystem. Durch Verwendung
des plattformabhängigen
Bytecodes und der Java-VM kann ein in der Java-Sprache geschriebenes
Programm auf jedem Rechnersystem ausgeführt werden. Dies ist insbesondere
in Netzwerken wie etwa dem Internet von Nutzen, die heterogene Rechnersysteme
untereinander verbinden.
-
Das
Interpretieren von Bytecodes macht jedoch Java-Programme um vieles
langsamer als vergleichbare C- oder C++-Programme. Ein Ansatz zur Verbesserung
dieser Leistungsfähigkeit
sind laufzeitnahe (JIT-)Compiler. Ein JIT-Compiler ist ein Compiler,
der als Teil einer virtuellen Java-Maschine läuft und, unmittelbar bevor
eine Methode zum ersten Mal ausgeführt wird, den Bytecode dynamisch
in Maschinencode übersetzt.
Dies kann eine wesentliche Beschleunigung gegenüber einem System erbringen, das
nur Bytecodes interpretiert. Eine JIT-Kompilierung besteht normalerweise
aus wenigen Phasen, die in der folgenden Reihenfolge ausgeführt werden: 1)
Bytecodes werden in eine plattformunabhängige Zwischendarstellung (IR)
konvertiert; 2) die IR wird unter Verwendung von Compiler-Optimierungstechniken
in eine optimierte IR transformiert; 3) die IR wird in plattformabhängigen Maschinencode
konvertiert.
-
Implementierungen
der virtuellen Java-Maschine werden auf Vorrichtungen mit begrenzten CPU- und Speichenessourcen
sehr beliebt. Auf solchen Vorrichtungen hat der oben erwähnte JIT-Kompilierungsprozeß einige
Nachteile. Zum Beispiel können
die Speicheranforderungen des Kompilierungsprozesses unerschwinglich
sein, weil jeder der Schritte Laufzeit-Speicheranforderungen hat,
die auf einer Vorrichtung mit begrenzten Ressourcen überzogen
sein können.
Ebenso können
die Speicheranforderungen zum Speichern der Übersetzung jeder Methode unerschwinglich
sein. Daher müssen
JITs auf diesen Vorrichtungen Entscheidungen treffen, welche Methoden
wirklich eine Kompilierung lohnen, und dürfen nur diese abwickeln. Außerdem müssen einige Übersetzungen
ausgesondert werden, um Platz für
neue zu schaffen. Das führt
zu einer langsameren Ausführung,
da die erneute Übersetzung
aufwendig ist.
-
Ein
weiterer Nachteil besteht darin, daß die Abwicklung der Bytecode-IR-Transformation
und der IR-Optimierung zur Laufzeit zu einer hohen Compilercodegröße führen kann.
Die dynamische Methodenauswahl zur Laufzeit hat in Bezug auf die
Compilercodegröße ebenfalls
ihren Preis.
-
Noch
ein weiterer Nachteil besteht darin, daß aufgrund der niedrigeren
Verarbeitungsleistung auf einer Maschine mit begrenzten Ressourcen
die Optimierungsphase nicht viel leisten kann, ohne die Ausführung des
Benutzerprogramms beträchtlich
zu verlangsamen.
-
Folglich
besteht der Bedarf an einem System und Verfahren zur Bytecodekompilierung,
das weniger speicherintensiv ist, zu schnellerer Kompilierung und
Ausführung
führt und
den Aufwand für
die erneute Kompilierung verringert.
-
EP0943990 beschreibt ein
Verfahren und System zur Bereitstellung von Optimierungsinformation
in einer codeinterpretierenden Umgebung. Genauer gesagt wird ein
Verfahren beschrieben, bei dem eingegebener Quellcode verarbeitet
wird, um Bytecode und Information zu erzeugen, die zur Laufzeit
verwendet werden kann, um die Ausführung durch eine codeinterpretierende
Umgebung wie etwa eine virtuelle Java-Maschine zu optimieren. Diese
Information kann Hinweise und/oder Anweisungen zur Optimierung der
Ausführung
des Bytecodes umfassen.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Verfahren
und Systeme gemäß den Prinzipien
der Erfindung ermöglichen
eine plattformunabhängige
selektive Im-Voraus-Kompilierung. Ein Methodenselektor wählt eine
Untermenge von Methoden zur Im-Voraus-Kompilierung aus. Für jede ausgewählte Methode
werden Bytecodes, die der ausgewählten
Methode entsprechen, in eine plattformunabhängige Zwischendarstellung konvertiert.
Die plattformunabhängige
Zwischendarstellung jeder ausgewählten
Methode wird optimiert, und jede optimierte Zwischendarstellung
wird mit einer entsprechenden ausgewählten Methode gespeichert.
-
Ein
Methodenselektor kann ein Profilierungswerkzeug umfassen, und eine
Heuristik kann eine Untermenge von Methoden zur Im-Voraus-Kompilierung
auswählen.
Das Profilierungswerkzeug stuft eine Menge von Methoden gemäß vorbestimmten Kriterien
ein, und die Heuristik kann die Untermenge von Methoden aus der
Menge der Methoden identifizieren. Ein Im-Voraus-Compiler kann eine
erste Einheit und eine zweite Einheit umfassen. Die erste Einheit
konvertiert für
jede ausgewählte
Methode Bytecodes, die der ausgewählten Methode entsprechen, in
eine plattformunabhängige
Zwischendarstellung. Die zweite Einheit optimiert die plattformunabhängige Zwischendarstellung
jeder ausgewählten
Methode. Jede optimierte Zwischendarstellung wird mit einer entsprechenden
ausgewählten
Methode gespeichert.
-
Ein
Klassen-Anfangslader kann vor der Laufzeit mindestens eine der ausgewählten Methoden zur
Ausführung
in eine Vorrichtung laden. Ein dynamischer Klassen-Anfangslader
kann zur Laufzeit mindestens eine der ausgewählten Methoden zur Ausführung in
die Vorrichtung laden. Eine virtuelle Maschine in der Vorrichtung
kann mindestens eine Methode entweder vom Klassen-Anfangslader oder vom
dynamischen Klassenlader empfangen. Ein Interpreter kann auf eine
Methodendeskriptor-Datenstruktur
einer aufzurufenden Methode zugreifen und bestimmen, ob der Methodendeskriptor-Datenstruktur eine
optimierte plattformunabhängige
Zwischendarstellung zugeordnet ist. Ein JIT-Compiler kann auf der
Grundlage einer Bestimmung, daß der
Methodendeskriptor-Datenstruktur eine optimierte plattformunabhängige Zwischendarstellung
zugeordnet ist, die der aufzurufenden Methode entsprechende optimierte
Zwischendarstellung in plattformabhängigen Maschinencode konvertieren.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Die
beigefügten
Zeichnungen sind in diese Patentschrift eingeschlossen und bilden
einen Teil derselben, und zusammen mit der Beschreibung erklären sie
die Merkmale und Prinzipien der Erfindung. Dabei zeigen diese folgendes:
-
1 ist
eine grafische Darstellung einer beispielhaften Netzwerkumgebung,
in der Merkmale und Aspekte gemäß der vorliegenden
Erfindung implementiert werden können;
-
2A ist
eine grafische Darstellung einer Vorrichtung gemäß der vorliegenden Erfindung;
-
2B ist
eine grafische Darstellung eines Servers gemäß der vorliegenden Erfindung;
-
3 ist
eine grafische Darstellung, die den Datenfluß zeigt, der die plattformunabhängige selektive
Im-Voraus-Kompilierung gemäß der vorliegenden
Erfindung betrifft;
-
4A ist
eine grafische Darstellung, die den Datenfluß zeigt, der die Arbeitsweise
eines Im-Voraus-Compilers
gemäß der vorliegenden
Erfindung betrifft;
-
4B ist
eine grafische Darstellung eines Methodenselektors gemäß der vorliegenden
Erfindung;
-
5 ist
ein beispielhafter Ablaufplan eines Verfahrens zur Im-Voraus-Kompilierung
von Methoden gemäß der vorliegenden
Erfindung;
-
6 ist
eine grafische Darstellung eines Methodendeskriptors mit einer als
Feld gespeicherten optimierten IR gemäß der vorliegenden Erfindung;
-
7 ist
eine grafische Darstellung eines Methodendeskriptors und zugehöriger Attribute
zur Verwendung beim dynamischen Laden von Klassen gemäß der vorliegenden
Erfindung; und
-
8 ist
ein beispielhafter Ablaufplan zur Ausführung von Prozessen gemäß der vorliegenden Erfindung.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Die
folgende ausführliche
Beschreibung der Erfindung nimmt auf die beigefügten Zeichnungen Bezug. Wenngleich
die Beschreibung beispielhafte Implementierungen aufweist, sind
andere Implementierungen möglich,
und an den beschriebenen Implementierungen können Änderungen vorgenommen werden,
ohne vom Geist und Schutzbereich der Erfindung abzuweichen. Die
folgende ausführliche
Beschreibung schränkt
die Erfindung nicht ein. Der Schutzbereich der Erfindung wird vielmehr
durch die beigefügten
Ansprüche
und ihre Äquivalente
definiert.
-
ÜBERSICHT
-
Verfahren
und Systeme gemäß der vorliegenden
Erfindung ermöglichen
plattformunabhängige
selektive Im-Voraus-Kompilierung. Ein Methodenselektor mit einem
Profilierungswerkzeug und Heuristik wählt eine Untermenge von Methoden
zur Im-Voraus-Kompilierung aus. Das Profilierungswerkzeug ordnet
eine Menge von Methoden gemäß vorbestimmten
Kriterien ein, und die Heuristik gibt die Untermenge von Methoden
aus der Menge der Methoden an. Ein Im-Voraus-Compiler umfaßt eine
erste Einheit und eine zweite Einheit. Die erste Einheit konvertiert
für jede
ausgewählte
Methode Bytecodes, die der ausgewählten Methode entsprechen,
in eine plattformunabhängige
Zwischendarstellung. Die zweite Einheit optimiert die plattformunabhängige Zwischendarstellung
jeder ausgewählten
Methode, wobei jede optimierte Zwischendarstellung mit einer entsprechenden
ausgewählten
Methode gespeichert wird. Ein Klassen-Anfangslader ist betriebsfähig, vor der
Laufzeit mindestens eine der ausgewählten Methoden zur Ausführung in
eine Vorrichtung zu laden. Ferner ist ein dynamischer Klassenlader
betriebsfähig,
zur Laufzeit mindestens eine der ausgewählten Methoden zur Ausführung in
die Vorrichtung zu laden.
-
Eine
virtuelle Maschine, die sich in einer Vorrichtung befindet, ist
betriebsfähig,
mindestens eine Methode entweder vom Klassen-Anfangslader oder vom
dynamischen Klassenlader zu empfangen. Ein Interpreter in der virtuellen
Maschine kann auf eine Methodendeskriptor-Datenstruktur einer aufzurufenden
Methode zugreifen und bestimmen, ob der Methodendeskriptor-Datenstruktur
eine optimierte plattformunabhängige
Zwischendarstellung zugeordnet ist. Ein JIT-Compiler in der virtuellen
Maschine kann auf der Grundlage einer Bestimmung, daß der Methodendeskriptor-Datenstruktur
eine optimierte plattformunabhängige
Zwischendarstellung zugeordnet ist, die der aufzurufenden Methode
entsprechende optimierte Zwischendarstellung in plattformabhängigen Maschinencode
konvertieren.
-
NETZWERKUMGEBUNG
-
1 ist
eine grafische Darstellung einer beispielhaften Netzwerkumgebung,
in der Merkmale und Aspekte gemäß der vorliegenden
Erfindung implementiert werden können.
Die Netzwerkumgebung 100 kann einen Zentralrechner 102,
Server 104a–104n,
Vorrichtungen 106a–106n und
das Netzwerk 108 aufweisen. Die Bestandteile von 1 können durch
Hardware, Software und/oder Firmware implementiert werden. Die Anzahl
der Bestandteile in der Netzwerkumgebung 100 ist nicht
auf das Gezeigte begrenzt.
-
Der
Zentralrechner 102 und die Server 104a–104n können Vorrichtungen 106a–106n mit Programmen
beliefern, die in einer plattformunabhängigen Sprache wie etwa Java
geschrieben sind. Zum Beispiel kann ein Softwareentwickler eines
oder mehrere Java-Programme erzeugen und zu Klassendateien kompilieren,
die Bytecodes enthalten, die durch eine virtuelle Maschine ausführbar sind,
wie etwa eine virtuelle Java-Maschine. Wenn eine Vorrichtung, wie
etwa die Vorrichtung 106a, ein Java-Progamm ausführen will,
kann sie eine Anforderung an einen Server erteilen, der das Programm
enthält,
wie etwa den Server 104a. Als Antwort sendet der Server 104a die
entsprechenden Klassendateien an die Vorrichtung 106a über einen
geeigneten Kommunikationskanal, wie etwa das Netzwerk 108 (das ein
leitungsgebundenes oder drahtloses Kommunikationsnetzwerk einschließlich des
Internet umfassen kann). Die Vorrichtung 106a kann die
Klassendateien in eine virtuelle Maschine laden, die sich in der Vorrichtung 106a befindet,
und die Ausführung
des Java-Programms fortsetzen. Alternativ kann eine Vorrichtung
ein Programm, wie etwa ein Java-Programm, vom Zentralrechner 102 über eine
direkte Verbindung oder von einer anderen Vorrichtung empfangen.
-
Der
Zentralrechner 102 kann eine CPU 110, einen Sekundärspeicher 112,
eine Eingabevorrichtung 114, eine Anzeigevorrichtung 116,
eine Kommunikationsvorrichtung 118 und einen Speicher 120 umfassen.
Der Speicher 120 kann das Betriebssystem 122,
den Compiler 124, den Quellcode 126, das Klassendatei-Repository 128,
der die Klassendateien 130 und die optimierte Zwischendarstellung
(IR) 132 aufweist, den Klassen-Anfangslader 134,
den Im-Voraus-Compiler 136 und den Methodenselektor 138 aufweisen.
Eine IR kann plattformunabhängige,
bezüglich
der Systemarchitektur neutrale Daten sein, die aus dem Quellcode
zu einem Format verarbeitet werden, das zu einem künftigen
Zeitpunkt schnell zu effizientem, optimiertem maschinenabhängigem Code
verarbeitet werden kann.
-
Der
Compiler 124 übersetzt
Quellcode in Klassendateien, die Bytecodes enthalten, die durch eine
virtuelle Maschine ausführbar
sind. Bei Quellcode 126 kann es sich um Dateien handeln,
die in der Programmiersprache Java geschriebenen Code enthalten.
Das Klassendatei-Repository 128 weist Klassendateien 130 und
optimierte IR 132 auf. Die Klassendateien 130 sind
Bytecodes, die durch eine virtuelle Maschine ausführbar sind,
und enthalten Daten, die eine bestimmte Klasse einschließlich Datenstrukturen,
Methodenimplementierungen und Verweisen auf andere Klassen darstellen.
Die optimierten IR 132 sind plattformunabhängige Zwischendarstellungen, die
unter Verwendung üblicher
Compilertechniken optimiert worden sind, und sind bestimmten Methoden
zugeordnet, die einer Im-Voraus-Kompilierung unterzogen
werden. Klassendateien und optimierte IR, die im Klassendatei-Repository 128 gespeichert sind,
können
entweder vorübergehend
oder für
längere
Zeit gespeichert werden.
-
Der
Klassen-Anfangslader 134 wird verwendet, um bestimmte Klassen
vor der Laufzeit in eine Vorrichtung mit einer virtuellen Maschine
vorab zu laden. Jede Java-Anwendung oder irgendeine andere Menge
von Methoden, die normalerweise zur Laufzeit geladen werden, können unter
Verwendung des Klassen-Anfangsladers 134 vorab geladen
werden. Die Arbeitsweise eines Klassen-Anfangsladers ist im US-Patent
Nr. 5966542 von Tock, auf das oben Bezug genommen wurde, genauer
beschrieben.
-
Der
Im-Voraus-Compiler 136 wickelt die plattformunabhängigen Teile
der Methodenkompilierung ab, wobei er den abschließenden,
plattformabhängigen
Teil der Methodenkompilierung einem JIT-Compiler überläßt, der
auf einer virtuellen Maschine läuft.
Zum Beispiel kann der Im-Voraus-Compiler 136 ein Profilierungswerkzeug
nutzen, um Methoden zu identifizieren, die vor der Laufzeit kompiliert
werden sollen. Danach führt
der Im-Voraus-Compiler 136 an den identifizierten Methoden eine
Bytecode-IR-Transformation
und eine IR-Optimierung durch. Die sich aus der Kompilierung jeder Methode
ergebende optimierte IR wird zusammen mit der Methode gespeichert.
-
Der
Methodenselektor 138 bestimmt, welche Methoden vor der
Laufzeit unter Verwendung des Im-Voraus-Compilers 136 kompiliert
werden sollen. Der Methodenselektor 136 kann ein Profilierungswerkzeug
auf Klassendateien anwenden, um eine geordnete Liste von Methoden
auf der Grundlage vorbestimmter Kriterien zu erzeugen. Diese geordnete
Liste wird mit einer Heuristik verwendet, um Methoden zu bestimmen,
die vor der Laufzeit kompiliert werden sollen.
-
2A ist
eine grafische Darstellung der Vorrichtung 106a mit mehr
Einzelheiten, wenngleich die anderen Vorrichtungen 106b–106n ähnliche
Bestandteile enthalten können.
Die Vorrichtung 106a kann eine CPU 202 aufweisen,
einen Sekundärspeicher 204,
eine Kommunikationsvorrichtung 206, eine Eingabevorrichtung 208,
eine Anzeigevorrichtung 210 und einen Speicher 212.
Der Speicher 212 kann ein Betriebssystem 214,
einen Browser 216, ein Klassendatei-Repository (Informationsbestand) 218,
eine virtuelle Maschine 222 und einen Laufzeit-Klassenlader 230 aufweisen.
-
Wenn
ein Benutzer der Vorrichtung 106a ein auf einem Server
wie etwa Server 104a gespeichertes Programm ausführen will,
dann kann der Benutzer den Browser 216 verwenden, um eine
Anforderung an den Server 104a zu erteilen. Als Antwort überträgt der Server 104a die
entsprechenden Klassendateien über
das Netzwerk 108 an die Vorrichtung 106a. Zum
Beispiel können
Klassendateien vom Server 104a entweder vorübergehend
oder für
längere
Zeit im Klassendatei-Repository 218 gespeichert werden.
Die Vorrichtung 106a kann die Klassendateien in eine virtuelle
Maschine wie etwa die virtuelle Maschine 222 laden, die
sich in der Vorrichtung 106a befindet, und die Ausführung des
Programms fortsetzen. Alternativ kann die Vorrichtung 106a Klassendateien
vom Klassendatei-Repository 218 laden, die nicht von einem
Server empfangen wurden. Zum Beispiel kann das Klassendatei-Repository 218 Klassendateien
vom Zentralrechner 102 zum späteren Laden in die virtuelle
Maschine empfangen.
-
Das
Klassendatei-Repository 218 kann vorab geladene Klassendateien 219 und
dynamisch geladene Klassendateien 220 aufweisen. Die vorab
geladenen Klassendateien 219 sind diejenigen Klassendateien,
die vor der Laufzeit in die Vorrichtung 106a geladen werden,
zum Beispiel unter Verwendung des Klassen-Anfangsladers 134 im
Zentralrechner 102. Die dynamisch geladenen Klassendateien 220 sind
diejenigen Klassendateien, die zur Laufzeit dynamisch geladen werden,
zum Beispiel unter Verwendung das Laufzeit-Klassenladers 230. Die
vorab geladenen Klassendateien 219 und die dynamisch geladenen
Klassendateien 220 können
optimierte IR aufweisen, die bestimmten Methoden zugeordnet sind,
die einer Im-Voraus-Kompilierung unterzogen wurden.
-
Die
virtuelle Maschine 222 kann vorab geladene Klassendateien 224,
einen JIT-Compiler 226 und einen Interpreter 228 aufweisen
und ist betriebsfähig,
Klassendateien auszuführen.
In einer Implementierung ist die virtuelle Maschine 222 eine
virtuelle Java-Maschine. Der Fachmann wird anerkennen, daß statt
dessen andere Arten von virtuellen Maschinen verwendet werden können. Die
vorab geladenen Klassendateien 224 sind diejenigen Klassendateien, die
vor der Laufzeit in die Vorrichtung 106a geladen werden,
zum Beispiel unter Verwendung des Klassen-Anfangsladers 134 im
Zentralrechner 102, und können optimierte IR aufweisen,
die bestimmten Methoden zugeordnet sind, die einer Im-Voraus- Kompilierung unterzogen
wurden. Die virtuelle Maschine 222 kann sowohl den JIT-Compiler 226 als
auch den Interpreter 228 nutzen, um die Ausführung von
Klassendateien zu unterstützen.
-
Der
JIT-Compiler 226 führt
entweder eine schnelle Kompilierung oder eine JIT-Kompilierung der
Methoden durch. Die schnelle Kompilierung kann erfolgen, wenn der
JIT-Compiler 226 eine Methode ausführt, die einer vorab berechneten
optimierten IR zugeordnet ist. Wenn der JIT-Compiler 226 zum
Beispiel eine Methode mit einer optimierten IR empfängt, konvertiert
er die IR in plattformabhängigen
Maschinencode, der dann durch die virtuelle Maschine 222 ausgeführt werden
kann. Die JIT-Kompilierung kann erfolgen, wenn der JIT-Compiler 226 eine
Methode ausführt,
die keiner vorab berechneten optimierten IR zugeordnet ist. Wenn
der JIT-Compiler 226 zum Beispiel eine Methode ohne optimierte
IR empfängt, kann
die Methode zur Laufzeit unter Verwendung der herkömmlichen
JIT-Kompilierung (zum Beispiel Bytecode-IR-Transformation, IR-Optimierung
und Codeerzeugung) ausgeführt
werden.
-
Der
Interpreter 228 interpretiert Java-Klassendateien ohne
Kompilierung in plattformabhängigen
Code. Der Interpreter 228 prüft Methoden, die durch die
virtuelle Maschine 222 ausgeführt werden, um zu bestimmen,
ob eine optimierte IR spezifischen Methoden zugeordnet ist. Wenn
eine Methode eine optimierte IR hat, dann veranlaßt der Interpreter 228 den
JIT-Compiler 226, eine schnelle Kompilierung der Methode
durchzuführen.
Anderenfalls kann der Interpreter 228 an einer Methode
weitere Tests durchführen,
um zu entscheiden, ob die Methode interpretiert oder durch einen
JIT-Compiler 226 unter Verwendung der JIT-Kompilierung
kompiliert werden sollte.
-
Der
Laufzeit-Klassenlader 230 lädt zur Laufzeit dynamisch Klassen
in den Adreßraum
eines Benutzers. Zum Beispiel kann ein Laufzeit-Klassenlader 230 zur
Laufzeit Klassendateien (die eine optimierte IR aufweisen können) von
einem lokalen Klassendatei-Repository holen, wie etwa dem Klassendatei-Repository 218,
oder von einem entfernt angeordneten Klassendatei-Repository in
einem Server oder einer anderen Vorrichtung. Diese Klassendateien
können dann
zur Ausführung
in geeigneter Weise verarbeitet werden.
-
2B ist
eine grafische Darstellung des Servers 104a mit mehr Einzelheiten,
wenngleich die anderen Vorrichtungen 106b–106n ähnliche
Bestandteile enthalten können.
Server 104a kann eine CPU 232, einen Sekundärspeicher 234,
eine Eingabevorrichtung 236, eine Anzeigevorrichtung 238, eine
Kommunikationsvorrichtung 240 und einen Speicher 242 aufweisen.
Der Speicher 242 kann ein Betriebssystem 244,
einen Compiler 246, Quellcode 248, ein Klassendatei-Repository 250,
das Klassendateien 252 und optimierte Zwischendarstellungen (IR) 254 aufweist,
und einen Klassen-Anfangslader 256 aufweisen.
Die verschiedenen Einheiten des Servers 104a funktionieren
auf ähnliche
Weise wie die ähnlich
benannten Einheiten des Zentralrechners 102.
-
Der
Server 104a kann Klassendateien 252 und optimierte
IR 254 vom Zentralrechner 102 empfangen, der die
Im-Voraus-Kompilierung durchführen kann.
Der Server 104a kann dann bei Bedarf die Klassendateien 252 und
optimierte IR 254 an eine Vorrichtung, wie etwa Vorrichtung 106a,
verteilen. Zum Beispiel kann der Server 104a den Klassen-Anfangslader 256 nutzen,
um vor der Laufzeit die geeigneten Daten in eine Vorrichtung 106a zu
laden. Alternativ kann ein Laufzeit-Klassenlader in der Vorrichtung 106a zur
Laufzeit Daten vom Klassendatei-Repository 250 holen.
-
3 ist
eine grafische Darstellung, die den Datenfluß zeigt, der die plattformunabhängige selektive
Im-Voraus-Kompilierung gemäß der vorliegenden
Erfindung betrifft. In der in 3 dargestellten grafischen
Darstellung führt
die Vorrichtung 304 ein Java-Programm aus, das sich ursprünglich im
Zentralrechner 302 befand. Der Java-Quellcode 306 wird an
den Java-Compiler 308 übergeben,
der den Java-Quellcode in Klassendateien 310 übersetzt,
die Bytecodes enthalten, die durch eine virtuelle Maschine ausführbar sind.
Die Klassendateien 310 können an den Methodenselektor 312 übergeben
werden. Der Methodenselektor 312 kann verschiedene Methoden
auswählen,
die vor der Laufzeit zu kompilieren sind, und die den Methoden zugeordneten
ausgewählten
Klassendateien 314 an den Im-Voraus-Compiler 316 weiterreichen,
der an einigen der ausgewählten
Klassendateien 314 eine Im-Voraus-Kompilierung durchführen kann.
-
Der
Im-Voraus-Compiler 316 führt an identifizierten Methoden
eine Im-Voraus-Kompilierung (zum Beispiel vor der Laufzeit) durch.
Zum Beispiel konvertiert der Im-Voraus-Compiler 316 zuerst
Bytecodes in eine IR. Als nächstes
optimiert der Im-Voraus-Compiler 316 die IR unter Verwendung üblicher
Compilertechniken. Der Im-Voraus-Compiler 316 veranlaßt auch,
daß die
optimierte IR zusammen mit den jeweiligen relevanten Methoden gespeichert
wird. Infolge dessen kann der Im-Voraus-Compiler 316 verschiedene
Klassendateien zusammen mit entsprechenden optimierten IR (Klassendateien
und optimierte IR 318) ausgeben, wenn es welche gibt. In
einer Implementierung kann der Im-Voraus-Compiler 316 auch bestimmte
Klassendateien ausgeben, denen keine optimierte IR zugeordnet ist,
so daß bestimmte
Klassendateien vom Im-Voraus-Compiler 316 optimierte IR
haben und andere nicht. Mehr Einzelheiten über die Arbeitsweise eines
Im-Voraus-Compilers werden unten mit Bezug auf 4–5 bereitgestellt.
-
Die
Klassendateien und optimierten IR 318 können ohne Vorab-Laden entweder
an den Klassen-Anfangslader 322 oder
an den lokalen Speicher in der Vorrichtung 304, wie etwa
ein Klassendatei-Repository
(wo der Laufzeit-Klassenlader 320 dann auf die Daten zugreifen
kann), übergeben
werden. Alternativ können
die Klassendateien und optimierten IR 318 zur späteren Verteilung
an eine Vorrichtung einem Server übergeben werden.
-
Der
Laufzeit-Klassenlader 320 kann Klassendateien zum gleichen
Zeitpunkt empfangen, zu dem er die zugehörige optimierte IR empfängt. Zum Beispiel
kann der Laufzeit-Klassenlader 320 Klassendateien und die
optimierten IR empfangen, wobei die optimierten IR als neue Attribute
in Methodendeskriptoren gespeichert werden. Der Klassen-Anfangslader 322 kann
jedoch die empfangenen Klassendateien zu einem anderen Zeitpunkt
empfangen als dem, zu dem er die zugehörige optimierte IR empfängt. Auf
diese Weise operiert der Klassen-Anfangslader 322 wie ein
Fließband
und speichert optimierte IR als ein Feld von Methodendeskriptoren,
so wie er sie empfängt.
Alternativ kann der Im-Voraus-Compiler 316 oder eine getrennte
Einheit (nicht gezeigt) optimierte IR als ein Feld von Methodendeskriptoren
in einer Klassendatei speichern, die zum Klassen-Anfangslader 322 weitergeleitet
wird. Obwohl der Laufzeit-Klassenlader 320 in 3 außerhalb
der virtuellen Java-Maschine 328 dargestellt ist, kann
der Laufzeit-Klassenlader 320 alternativ teilweise oder
gänzlich
innerhalb der virtuellen Java-Maschine 328 sein.
-
Der
Laufzeit-Klassenlader 320 und der Klassen-Anfangslader 322 laden
Klassendateien dynamisch beziehungsweise vor der Laufzeit in die
Vorrichtung 304. Sowohl vorab geladene Klassendateien 326 als
auch dynamisch geladene Klassendateien 324 können optimierte
IR aufweisen, die als Feld von Methodendeskriptoren gespeichert
sind, die Methoden entsprechen, die vor der Laufzeit kompiliert
wurden. Vorab geladene Klassendateien 326 werden vor der
Laufzeit in der Vorrichtung 304 gespeichert. Folglich muß, wenn
einer Methode eine optimierte IR zugeordnet ist, die optimierte
IR entweder durch den Klassen-Anfangslader 322 oder eine
Einheit außerhalb
des Klassen-Anfangsladers 322 als ein Feld im Methodendeskriptor
gespeichert werden, bevor die Laufzeit beginnt. Obwohl die vorab
geladenen Klassendateien 326 in 3 als anfänglich außerhalb
der virtuellen Java-Maschine 328 dargestellt sind, können sich
einige oder alle vorab geladenen Klassendateien 326 alternativ
in der virtuellen Java-Maschine 328 befinden. Der Laufzeit-Klassenlader 320 empfängt Klassendateien
und optimierte IR zur Laufzeit von einem Server, einer anderen Vorrichtung
oder einem lokalen Speicher und erzeugt dann dynamisch geladene
Klassendateien 324. Folglich kann eine Methode mit einer
entsprechenden optimierten IR die optimierte IR entweder zur Laufzeit
oder vor der Laufzeit in ihrem Methodendeskriptor gespeichert haben. Mehr
Einzelheiten über
die Speicherung der optimierten IR mit einer Methode werden unten
mit Bezug auf 4–7 bereitgestellt.
-
Dynamisch
geladene Klassendateien 324 und/oder vorab geladene Klassendateien 326 werden
an die virtuelle Java-Maschine 328 übergeben, wobei der JIT-Compiler 330,
der Interpreter 332, Dienste vom zugrundeliegenden Betriebssystem 334 und
die Rechner-Hardware (nicht gezeigt) die Ausführung der Klassendateien unterstützen. Der
Interpreter 332 erkennt, ob einer bestimmten Methode eine
optimierte IR zugeordnet ist, und kann denn JIT-Compiler 330 veranlassen,
die Methode unter Verwendung der schnellen Kompilierung zu kompilieren
(zum Beispiel mit Überspringen
der Bytecode-IR-Transformation und der IR-Optimierung), wenn es eine solche optimierte
IR gibt. Mehr Einzelheiten über
die Arbeitsweise eines JIT-Compilers und
Interpreters gemäß der vorliegenden
Erfindung werden unten mit Bezug auf 8 bereitgestellt.
-
4A ist
eine grafische Darstellung, die den Datenfluß zeigt, der die Arbeitsweise
eines Im-Voraus-Compilers
gemäß der vorliegenden
Erfindung betrifft. Bytecodes 404 aus einer Klassendatei werden
an den Methodenselektor 406 übergeben, der außerhalb
des Im-Voraus-Compilers 402 sein kann, wo vor der Laufzeit
zu kompilierende Methoden ausgewählt
werden. Alternativ kann der Methodenselektor 406 innerhalb
des Im-Voraus-Compilers 402 sein. Der Methodenselektor 406 kann
anschließend ausgewählte Bytecodes 408,
die den ausgewählten Methoden
zugeordnet sind, an den Im-Voraus-Compiler 402 senden.
Insbesondere werden ausgewählte Bytecodes 408 an
die Bytecode-IR-Transformationseinheit 410 gesendet. Die
ausgewählten
Bytecodes 408 werden zur Konvertierung in plattformunabhängige Zwischendarstellungen
(IR) an die Bytecode-IR-Transformationseinheit 410 übergeben.
Die IR 412 werden an die IR-Optimierungseinheit 414 übergeben,
wo sie unter Verwendung üblicher
Compilertechniken in optimierte IR 416 geändert werden. Danach
werden die optimierten IR 416 zusammen mit den relevanten
Methoden gespeichert (Speicher 418). Die optimierten IR
und die entsprechenden Methoden werden zur Verwendung durch einen
Klassen-Anfangslader oder einen Laufzeit-Klassenlader verfügbar gemacht.
-
4B ist
eine grafische Darstellung eines Methodenselektors 406 mit
mehr Einzelheiten. Das Profilierungswerkzeug 420 wird auf
Klassendateien oder Java-Quellcode angewendet, um auf der Grundlage
vorbestimmter Kriterien eine geordnete Liste von Methoden zu erzeugen.
Zum Beispiel kann das Profilierungswerkzeug 420 Methoden
gemäß der Anzahl
der Aufrufe, der Ausführungszeit,
der Speichergröße, einer
vorbestimmten Liste, zufällig
und anhand verschiedener anderer Faktoren einstufen. Die Heuristik 422 kann
die durch das Profilierungswerkzeug 420 erzeugte Liste
prüfen
und unter Verwendung von durch den Entwickler ausgewählten Kriterien
bestimmen, welche spezifischen Methoden von der Liste vor der Laufzeit
kompiliert werden sollen. Das Profilierungswerkzeug 420 und
die Heuristik 422 müssen
nicht Teil der gleichen Einheit (zum Beispiel des Methodenselektors 406)
sein. Außerdem kann
sich das Profilierungswerkzeug 420 in einer Vorrichtung
mit einer virtuellen Maschine befinden. In einer solchen Konfiguration
kann das Profilierungswerkzeug 420 Statistiken über Programme
sammeln, während
sie in der virtuellen Maschine aufgeführt werden, und anschließend der
Heuristik (die sich auf einem Zentralrechner, einem Server, einer
anderen Vorrichtung oder der gleichen Vorrichtung wie das Profilierungswerkzeug
befinden kann) eine geordnete Liste von Methoden zur weiteren Verarbeitung
senden.
-
5 ist
ein beispielhafter Ablaufplan eines Verfahrens zur Im-Voraus-Kompilierung
von Methoden gemäß der vorliegenden
Erfindung. Der Ablaufplan von 5 entspricht
dem Datenfluß von 4. Wenngleich die Schritte des Ablaufplans
in einer bestimmten Reihenfolge beschrieben sind, wird der Fachmann
anerkennen, daß diese
Schritte auch in einer anderen Reihenfolge durchgeführt werden
können,
oder daß einige
dieser Schritte gleichzeitig erfolgen können.
-
Zuerst
identifiziert ein Methodenselektor die Methoden, die vor der Laufzeit
kompiliert werden sollen (Schritt 502). Zum Beispiel kann
ein Profilierungswerkzeug des Methodenselektors eine Anwendung oder
eine Menge von Anwendungen ausführen
(zum Beispiel Java-Quellcode oder Bytecodes). Während das Profilierungswerkzeug
die Anwendungen ausführt,
kann es Statistiken über
die verschiedenen Methoden in den Anwendungen sammeln. Das Profilierungswerkzeug
kann dann eine geordnete Liste von Methoden erzeugen, die gemäß vorbestimmten
Kriterien eingestuft werden. Zum Beispiel kann das Profilierungswerkzeug
bestimmen, welche Methoden am meisten aufgerufen werden und die
Methoden dementsprechend einstufen, mit der am meisten aufgerufenen
Methode an erster Stelle. Ein anderer Faktor, den das Profilierungswerkzeug
verwenden kann, ist die Speichergröße. Zum Beispiel kann das Profilierungswerkzeug
Methoden gemäß der Speichergröße einstufen,
weil der zum Speichern einer IR verfügbare Platz begrenzt sein kann.
Andere Faktoren, die verwendet werden können, um die Bestimmung zu unterstützen, wie
Methoden anfänglich
eingestuft werden, weisen die Ausführungszeit, eine durch einen
Entwickler vorbestimmte Liste oder eine zufällige Einstufung auf. Der Fachmann
wird anerkennen, daß die
oben erwähnten
Faktoren jeweils als einzige Grundlage oder in einer bestimmten
Kombination miteinander zur Einstufung verwendet werden können und
daß zusätzliche
Faktoren, die hier nicht eigens aufgeführt sind, verwendet werden
können.
-
Sobald
das Profilierungswerkzeug eine geordnete Liste von Methoden erzeugt,
verwendet es die geordnete Liste mit einer Heuristik, um zu bestimmen,
welche der am meisten verwendeten Methoden vor der Laufzeit kompiliert
werden soll. Die Heuristik kürzt
im wesentlichen die durch das Profilierungswerkzeug erzeugte Liste.
Die gekürzte
Liste umfaßt die
Methoden, die vor der Laufzeit kompiliert werden sollen. Ein Entwickler
kann die Kriterien wählen,
die die Heuristik verwendet, um genau zu bestimmen, welche Methode
ausgewählt
werden soll. Zum Beispiel kann ein Entwickler entscheiden, daß nur die ersten
zehn Methoden auf der geordneten Liste vor der Laufzeit kompiliert
werden sollen oder daß nur Methoden,
die häufiger
als mit einer bestimmten Häufigkeit
aufgerufen wurden, ausgewählt
werden sollen. Alternativ kann der Entwickler festlegen, daß eine bestimmte
Anzahl von zufälligen
Methoden von der geordneten Liste ausgewählt werden sollen oder daß nur diejenigen
Methoden von einer vorbestimmten Liste ausgewählt werden sollen, die zu den
ersten 40 Methoden der geordneten Liste gehören. Der Fachmann wird anerkennen,
daß der
Entwickler Kriterien auswählen
kann, die hier nicht eigens erwähnt werden,
um zu bestimmen, welche Methoden von einer geordneten Liste vor
der Laufzeit kompiliert werden sollen. Der oben beschriebene Methodenselektor
(zum Beispiel das Profilierungswerkzeug und die Heuristik) kann
Teil eines Im-Voraus-Compilers, oder er kann eine getrennte Einheit
sein.
-
Für jede Methode,
die als Methode identifiziert wurde, die vor der Laufzeit kompiliert
werden soll (Schritt 504), konvertiert der Im-Voraus-Compiler die
Bytecodes der Methode in eine Zwischendarstellung (IR) (Schritt 506).
Der Im-Voraus-Compiler optimiert auch die IR jeder identifizierten
Methode (Schritte 508, 510). Eine IR kann unter
Verwendung üblicher
Compilertechniken optimiert werden. Weil die Techniken vor der Laufzeit
genutzt werden, können
Compilertechniken genutzt werden, die für eine Berechnung zur Laufzeit
zu aufwendig wären.
Beispiele für
solche Techniken weisen globalen gemeinsamen Teilausdruck, schleifeninvariantes
Verschieben, Eliminierung gemeinsamer Teilausdrücke und Liveness-Analyse auf.
Der Fachmann wird anerkennen, daß andere Compilertechniken
verwendet werden können.
-
Nachdem
die Zwischendarstellungen (IR) optimiert worden sind, kann der Im-Voraus-Compiler veranlassen,
daß die
optimierte IR jeder identifizierten Methode zusammen mit ihrer entsprechenden Methode
gespeichert wird (Schritte 512, 514). Die optimierten
IR können
auf zwei unterschiedliche Arten gespeichert werden. Die Art der
Speicherung ist davon abhängig,
ob Klassen, die den optimierten IR zugeordnet sind, vorab geladen
oder dynamisch geladen werden. Wenn eine einer optimierten IR zugeordnete
Klasse anfänglich
dafür bestimmt
ist, vorab geladen zu werden, wird die optimierte IR als Feld der
Methodendeskriptor-Datenstruktur der Methode gespeichert, die kompiliert
wurde, um die optimierte IR zu erzeugen. Alternativ kann der Methodendeskriptor
einen Zeiger auf die optimierte IR enthalten, statt die optimierte
IR selbst zu enthalten. Der Methodendeskriptor kann auch ein Flag
enthalten, das angibt, daß der
Methode eine optimierte IR zugeordnet ist. Sobald die optimierte
IR mit dem Methodendeskriptor gespeichert worden ist, kann der Klassen-Anfangslader
fortfahren, indem er den Methodendeskriptor vorab lädt oder
den Methodendeskriptor für späteres dynamisches
Laden durch den Laufzeit-Klassenlader speichert.
-
6 ist
eine beispielhafte grafische Darstellung eines Methodendeskriptors,
der eine als Feld gespeicherte optimierte IR hat. Ein Fachmann wird
anerkennen, daß der
Methodendeskriptor 600 nicht auf die spezifischen in 6 dargestellten
Felder beschränkt
ist. Der Methodendeskriptor 600 weist den Methodennamen 602,
Parameter 604, den Rückgabetyp 606,
Flags 608, die IR 610 und Bytecode 612 auf.
Der Methodenname 602 stellt den Namen dar, der zu verwenden
ist, wenn auf die Methode verwiesen wird. Die Parameter 604 sind
eine Liste von Argumenten, die Methode verwendet. Jeder Parameter
ist ein Java-Klassentyp.
Der Rückgabetyp 606 ist
ein Java-Klassentyp, der durch die Methode bei Ausführung zurückgegeben
wird. Die Flags 608 sind eine Anzahl von Indikatoren, die
verwendet werden, um verschiedene Attribute der Methode zu bezeichnen.
Die Flags 608 können
ein Flag aufweisen, das angibt, daß der Methode eine IR zugeordnet
ist. Die IR 610 ist eine plattformunabhängige Zwischendarstellung (IR),
die aus der Im-Voraus-Kompilierung der Methode entstanden ist. Die
IR 610 kann die IR selbst oder ein Zeiger auf die IR sein.
Die Bytecodes 612 sind die Bytecodes und Zusatzinformation,
die benötigt
werden, um die Methode in Fällen
zu implementieren, wo die IR letzten Endes nicht kompiliert wird.
-
Wenn
eine Klasse, die einer optimierten IR zugeordnet ist, anfänglich dafür bestimmt
ist, dynamisch geladen zu werden, wird die IR als ein neues Attribut
des Methodendeskriptors für
die Methode gespeichert. Folglich kann, wenn ein Programm, das durch
eine virtuelle Maschine in einer Vorrichtung ausgeführt wird,
eine Methode mit einer optimierten IR von einem Server benötigt (oder
von einer anderen Vorrichtung oder einem lokalen Speicherbereich in
der gleichen Vorrichtung), ein Laufzeit-Klassenlader die geeignete
Klassendatei in die Vorrichtung laden. Wenn der Laufzeit-Klassenlader
dafür programmiert
ist, das neue Attribut zu erkennen, die der IR entspricht, greift
er vor dem Laden auf das IR-Attribut zu und speichert die IR als
ein Feld im Methodendeskriptor (die IR selbst oder ein Zeiger auf
die IR können
als ein Feld gespeichert werden). Auch wird der Methodendeskriptor
als eine IR enthaltend identifiziert. Auf diese Weise kann der Laufzeit-Klassenlader
den Methodendeskriptor in einen Methodendeskriptor transformieren,
der demjenigen ähnelt,
der normalerweise zum Vorab-Laden verwendet wird. Alternativ kann
ein Im-Voraus-Compiler das IR-Attribut erkennen, die IR als ein
Feld im Methodendeskriptor speichern und den Methodendeskriptor
als eine IR enthaltend identifizieren. Außerdem kann ein Profilierungswerkzeug
diese Schritte während
der Entwicklungszeit durchführen
(zum Beispiel außerhalb
der Laufzeit).
-
7 ist
eine beispielhafte grafische Darstellung eines Methodendeskriptors
und zugehöriger Attribute
zur Verwendung beim dynamischen Klassenladen. Ein Fachmann wird
anerkennen, daß der Methodendeskriptor 700 nicht
auf die spezifischen in 7 dargestellten Felder begrenzt
ist und daß dem Deskriptor
zusätzliche
Attribute zugeordnet sein können.
Der Methodendeskriptor 700 weist den Methodennamen 702,
Parameter 704, den Rückgabetyp 706,
Attribute 708 und Flags 710 auf. Die Attribute 708 weisen
eine Liste von Attributsstrukturen zur Verwendung in Verbindung
mit der Methode auf. Um die Attribute richtig zu verarbeiten, muß eine virtuelle
Maschine, ein Laufzeit-Klassenlader oder ein Im-Voraus-Compiler in der Lage sein, die
Attributsstrukturen zu erkennen und korrekt zu lesen. Das "Code"-Attribut 712 weist die Bytecodes
und Zusatzinformation auf, die erforderlich ist, um die Methode
zu implementieren. Das "Compiler
IR"-Attribut 714 weist
eine plattformunabhängige
Zwischendarstellung auf, die aus der Im-Voraus-Kompilierung der
Methode entstanden ist. Wenn der Laufzeit-Klassenlader oder der Im-Voraus-Compiler
das "Compiler IR"-Attribut 714 und
das "Code"-Attribut 712 erkennt,
schließt
er den Bytecode und die IR dieser Attribute als Felder des Methodendeskriptors 700 ein
(zum Beispiel speichert er den Bytecode und die IR im Methodendeskriptor).
-
8 ist
ein beispielhafter Ablaufplan zur Ausführung von Methoden gemäß der vorliegenden Erfindung.
Obwohl die Schritte des Ablaufplans in einer bestimmten Reihenfolge
beschrieben werden, wird der Fachmann anerkennen, daß diese
Schritte in einer anderen Reihenfolge durchgeführt werden können oder
daß einige
dieser Schritte gleichzeitig erfolgen können.
-
Wenn
eine virtuelle Maschine wie etwa die virtuelle Maschine 222 ein
Programm ausführt,
werden verschiedene Methoden entweder als Teil des Vorab-Ladens
oder des dynamischen Klassenladens in die virtuelle Maschine geladen.
Wenn der Laufzeit-Klassenlader erkennt, daß Methoden, die das "Compiler IR"-Attribut enthalten,
als Teil des dynamischen Klassenladens geladen werden, wird die
IR ein Feld der Methodendeskriptor-Datenstruktur, bevor sie in die
virtuelle Maschine geladen wird. Ebenso wird der Methodendeskriptor
als eine IR enthaltend identifiziert. Alternativ kann die IR des "Compiler IR"-Attributs vor der
Laufzeit in der Methodendeskriptor-Datenstruktur gespeichert werden.
Vorab geladenen Methoden mit einer IR sind schon identifiziert und
wiesen als ein Feld die IR auf. Während die virtuelle Maschine
die Ausführung
eines Programms fortsetzt, greift der Interpreter der virtuellen
Maschine immer dann, wenn eine Methode aufgerufen werden soll, auf
den Methodendeskriptor der aufzurufenden Methode zu (Schritt 802).
-
Als
nächstes
nimmt der Interpreter eine Bestimmung vor, ob die aufzurufende Methode
eine vorberechnete IR hat (Schritt 804). Insbesondere prüft der Interpreter
die Flags des Methodendeskriptors, um zu sehen, ob es ein Flag gibt,
das angibt, daß der Methode
eine IR zugeordnet ist. Wenn es eine der Methode zugeordnete IR
gibt, dann gibt der Interpreter die IR an einen JIT-Compiler weiter
(Schritt 806). Alternativ kann die virtuelle Maschine,
statt die IR automatisch an den JIT-Compiler zu senden, die Methode
weiteren Tests unterziehen, um zu bestimmen, ob die IR kompiliert
werden soll. Zum Beispiel kann die virtuelle Maschine Faktoren wie
etwa Speichernutzung zur Laufzeit, Prozessornutzung, Benutzerentscheidung
(zum Beispiel entscheidet der Benutzer, daß er nicht möchte, daß die IR
kompiliert wird), Ausführungszeit
und/oder Fuzzy-Logik verwenden, um zu entscheiden, ob die IR kompiliert
werden soll. Wenn die virtuelle Maschine bestimmt, daß die Methode
immer noch kompiliert werden soll, kann der Interpreter die IR an
den JIT-Compiler weiterleiten. Wenn die virtuelle Maschine entscheidet,
daß die
IR nicht kompiliert werden soll, dann setzt der Interpreter die
Interpretation der Methode ohne Kompilierung fort.
-
Nach
Empfang der IR schließt
der JIT-Compiler die Kompilierung der Methode ab, indem er eine schnelle
Kompilierung an ihr durchführt
(Schritt 808). Zum Beispiel kann der JIT-Compiler die optimierte
IR in maschinenabhängigen
Code übersetzen
(zum Beispiel Code-Erzeugung). Die Schritte der Bytecode-IR-Transformation
und IR-Optimierung, die normalerweise Teil einer JIT-Kompilierung
sind, werden nicht durchgeführt.
Nachdem die schnelle Kompilierung durchgeführt worden ist, setzt die virtuelle
Maschine die Ausführung
fort (Schritt 810). Insbesondere springt die virtuelle
Maschine zum nunmehr kompilierten Code der Methode. Nachdem die
virtuelle Maschine die Methode ausgeführt hat, kann die Ausführung des
restlichen Java-Programms weitergehen. Wenn die Ausführung nicht
zum Aufruf weiterer Methoden führt,
dann geht die Ausführung
weiter, bis sie abgeschlossen ist (Schritt 812 – Nein).
Wenn die virtuelle Maschine bestimmt, daß eine andere Methode aufzurufen
ist, dann kann auf den geeigneten Methodendeskriptor zugegriffen
werden, und er kann wie oben beschrieben ausgeführt werden (Schritt 812 – Ja).
-
Wenn
der Interpreter bestimmt, daß eine
aufzurufende Methode keine vorberechnete IR hat (oder wenn der Interpreter
nicht dafür
programmiert ist, zu erkennen, ob eine Methode eine vorberechnete
IR hat), dann trifft der Interpreter eine Entscheidung darüber, ob
eine JIT-Kompilierung verfügbar
ist (Schritt 814). Zum Beispiel kann der Interpreter ein
Flag oder einen anderen dem JIT-Compiler zugeordneten Indikator
prüfen,
um zu bestimmen, ob der JIT-Compiler dafür konfiguriert ist, eine JIT-Kompilierung
durchzuführen. "JIT-Kompilierung" bezeichnet eine
Kompilierung, die mindestens Bytecode-IR-Transformation, IR-Optimierung und Code-Erzeugung
einschließt. Wenn
der Interpreter bestimmt, daß eine
JIT-Kompilierung verfügbar
ist, trifft der JIT-Compiler eine Bestimmung, ob die aufzurufende
Methode eine Kompilierung lohnt (Schritt 816). Zum Beispiel
kann es sein, daß eine
Methode keine Kompilierung lohnt, wenn der Bytecode so kurz ist,
das es die Zeit nicht wert wäre,
die erforderlich wäre,
um den Bytecode zu kompilieren. Wenn der JIT-Compiler bestimmt,
daß die
Methode die Kompilierung lohnt, dann fährt er fort, indem er die Methode
unter Verwendung der JIT-Kompilierung kompiliert (Schritt 818).
-
Danach
setzt die virtuelle Maschine die Ausführung mit einem Sprung zum
nunmehr kompilierten Code der Methode fort.
-
Wenn
der Interpreter bestimmt, daß keine JIT-Kompilierung
verfügbar
ist oder wenn der JIT-Compiler
bestimmt, daß eine
Methode keine Kompilierung lohnt, dann fährt der Interpreter damit fort,
die Methode ohne Kompilierung zu interpretieren (Schritt 820).
Die virtuelle Maschine kann dann die Ausführung des restlichen Java-Programms
fortsetzen.
-
Wenngleich
die vorliegende Erfindung in Verbindung mit verschiedenen Ausführungsformen
beschrieben worden ist, werden für
den Fachmann ohne weiteres viele Modifikationen offensichtlich sein.
Obwohl Aspekte der vorliegenden Erfindung so beschrieben wurden,
daß sie
im Speicher gespeichert sind, wird der Fachmann anerkennen, daß diese
Aspekte auch in anderen Arten von computerlesbaren Medien gespeichert
oder davon gelesen werden können,
wie etwa Sekundärspeichervorrichtungen
wie Festplatten, Disketten, oder CD-ROM; einer Trägerwelle,
einem optischen Signal oder einem digitalen Signal von einem Netzwerk,
wie etwa dem Internet; oder anderen Formen von RAM oder ROM, die
entweder derzeit bekannt sind oder später entwickelt werden. Außerdem wird
der Fachmann anerkennen, obwohl eine Anzahl der Softwarebestandteile
so beschrieben wurde, daß sie
sich in der gleichen Maschine befinden, daß diese Bestandteile über eine Anzahl
von Maschinen verteilt sein können.
Die Erfindung ist darum nicht auf die Offenbarung hier begrenzt,
sondern es ist beabsichtigt, daß sie
jegliche Anpassungen oder Variationen davon abdeckt.