-
Hintergrund der Erfindung
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft im allgemeinen die Bestimmung von
Beziehungen zwischen Objekten in auf Objekten beruhenden Systemen.
Insbesondere betrifft die vorliegende Erfindung die effiziente Durchführung von Überprüfungen von
Untertypen bei Objekten in Systemen, die auf Objekten beruhen.
-
Beschreibung
des Standes der Technik
-
Viele
auf Objekten beruhende Rechensysteme sind derart strukturiert, dass
die Objekte Mitglieder spezieller Klassen und Unterklassen sind,
die die Leistungsfähigkeit
vorgeben, die den Objekten zur Verfügung steht. Während der
Ausführung
eines Programms überprüft eine
virtuelle Maschine typischerweise die Beziehungen zwischen den Objekten,
um die Ausführung
des Programms zu erleichtern. Eine virtuelle Maschine kann beispielsweise
Unterklassen- oder Untertypenbeziehungen zwischen Objekten überprüfen. In
einigen Programmsprachen, z.B. der Programmsprache Java, die von
Sun Microsystems, einer in Palo Alto, Kalifornien, ansässigen Gesellschaft,
entwickelt wurde, schließen
die Konstruktionen in den Programmsprachen Unterklassenüberprüfungen mit
ein. Die Unterklassenüberprüfungen führen im
allgemeinen zu einer Feststellung, ob ein bestimmtes Objekt zu einem
vorgegebenen Typ gehört.
Das heißt,
die Klassenstrukturen, die mit dem Programm verbunden sind, werden überprüft, um den
Typ des speziellen Objekts zu bestimmen.
-
1 ist
eine schematische Darstellung einer herkömmlichen Klassenstruktur. Eine
Klassenstruktur 102, d.h. eine Klassenhierarchie, enthält eine Klasse 106 und
die Unterklassen 110. Im allgemeinen ist die Klasse 106 eine
abstrakte Klasse, die eine beliebige Anzahl von Unterklassen 110 enthalten kann.
Wie gezeigt ist, sind die Unterklasse "1" 110a, die
Unterklasse "2" 110b und
die Unterklasse "N" 110c "direkte" Unterklassen der
Klasse 106, während die
Unterklasse "A1" 110d eine
direkte Unterklasse der Unterklasse "1" 110a ist.
Die Unterklasse "A1" 110d kann
als eine indirekte Unterklasse der Klasse 106 angesehen
werden, da die Unterklasse "A1" 110d eine
Unterklasse der Unterklasse "1" 110a ist, die
eine Unterklasse der Klasse 106 ist.
-
Die
Klasse 106 enthält
typischerweise mehrere verschiedene Funktionen oder Verfahren. Jede Unterklasse 110 enthält im allgemeinen
einen unterschiedlichen Satz von Funktionen. Die Unterklasse "1" 110a enthält im allgemeinen Funktionen,
die für Objekte
spezifisch sind, die ein Teil der Unterklasse "1" 110a sind.
Ein Objekt, das ein Mitglied der Klasse 106 ist, kann im
wesentlichen alle Funktionen ausführen, die mit der Klasse 106 verbunden
sind. Jedes Objekt, welches ein Mitglied einer der Unterklassen 110 ist,
ist auch Mitglied der Klasse 106. Als solches kann ein
Objekt, welches ein Mitglied einer der Unterklassen 110 ist,
auch die Funktionen ausführen,
die mit Klasse 106 verbunden sind. Ein Objekt, welches ein
Mitglied einer bestimmten Unterklasse ist, beispielsweise der Unterklasse "1" 110a, kann die spezifischen
Funktionen, die mit einer anderen Unterklasse, z.B. der Unterklasse "2" 110b verbunden sind, nicht
ausführen.
Daher werden durch eine Bestimmung, zu welcher Unterklasse 110 ein Objekt
gehört,
effektiv die Funktionen bestimmt, die ein Objekt ausführen kann.
-
In
Laufzeit kann ein einengender Blick dazu eingesetzt werden, um ein
durch Klasse 106 definiertes Objekt als ein durch Unterklasse "1" 110a definiertes Objekt effektiv
zu erkennen. Da aber das Objekt, das durch Klasse 106 definiert
ist, eher durch die Unterklasse "2" 110b definiert
sein kann, als durch die Unterklasse "1" 110a,
erfolgt typischerweise eine Überprüfung, um
zu bestimmen, ob die Verbindung des Objekts mit der Unterklasse "1" 110a richtig ist. Wie dem
Fachmann auf diesem Gebiet einleuchtet, ist eine Überprüfung, ob
ein Objekt mit Unterklasse "1" 110a verbunden
ist, effektiv die Überprüfung einer Bestimmung,
ob das Objekt mindestens mit Unterklasse "1" 110a verbunden
ist. Mit anderen Worten wird von einem Objekt, das mit der Unterklasse "A1" 110d verbunden
ist, im allgemeinen auch bestimmt, dass es mit der Unterklasse "1" 110a verbunden ist.
-
In
einer Java-Umgebung kann eine Funktion, die den Untertypen eines
Objektes bestimmt, z.B. eine is_subtype-Funktion, statisch codiert
werden. Während
die Verfahren, die verwendet werden, um die Funktion statisch zu
codieren, verschieden sein können,
umfaßt
ein Verfahren, das allgemein angewendet wird, die Verwendung einer
zweidimensionalen Bit-Matrix, bei der ein Bit an einer Stelle, definiert durch
(i, j), das Ergebnis is_subtype (ti, tj) codiert. Wenn eine solche
Matrix verwendet wird, bezieht eine Untertypenüberprüfung das Aufnehmen in die Matrix
zur Bestimmung des Untertypen eines Objekts effektiv mit ein. Die
Matrix kann jedoch eine bedeutende Größe aufweisen, und die Untertypenüberprüfungen sind
oft langsam wegen der typischerweise notwendigen Bitmanipulation
der Instruktionen.
-
Wenn
Untertypenüberprüfungen vorgenommen
werden, müssen
typischerweise im wesentlichen alle Untertypen eines Typs, z.B.
im wesentlichen alle Unterklassen einer Klasse, überprüft werden, um den Untertypen
eines bestimmten Objektes zu bestimmen. In einigen hierarchischen
Klassenstrukturen, z.B. der Klassenstruktur 102 von 1, kann
die Anzahl der zu überprüfenden Unterklassen relativ
hoch sein. Beispielsweise können
einige Klassen Hunderte von mit ihnen verbundenen Unterklassen aufweisen.
Die Durchführung
von Untertypenüberprüfungen an
sich erweist sich oft als ineffizient, wenn mehrere Subtypen verfügbar sind,
wie das bei Schnittstellen der Fall ist, die in der Programmsprache
Java vorgegeben sind. Das heißt,
wenn mehrere Subtypen verfügbar
sind, ist die Überprüfung jedes Subtyps
typischerweise zeitaufwendig, wie oben angegeben. Darüber hinaus
ist die Durchführung
von Untertypenüberprüfungen in
einem System, das mehrere Erbschichten (inheritance layers) verwendet,
z.B. Systeme, die in der Programmsprache C++ definiert sind, ebenfalls
oft ineffizient. Für
ein System mit mehreren Erbschichten sind Untertypenüberprüfungen im
allgemeinen wegen der Tatsache, dass jede Erbschicht überprüft werden
muß, nur
schwer in effizienter Weise durchzuführen.
-
Die
Durchführung
effizienter Untertypenüberprüfungen ist
deshalb wichtig, weil Überprüfungen häufig stattfinden
können.
Wenn die Überprüfungen während der
Ausführung
eines Programms häufig stattfinden,
können
die allgemeinen Unkosten in Verbindung mit den Überprüfungen relativ hoch sein. In einigen
Fällen,
einer Laufzeit-Untertypenüberprüfung, oder
einem Laufzeit-Untertypentest
können etwa
acht Instruktionen erforderlich sein, was, wie dem Fachmann auf
diesem Gebiet einleuchtet, für das
Gesamtprogramm signifikant sein kann, insbesondere wenn wiederhole
Laufzeit-Untertypenüberprüfungen erfolgen.
Die häufigen
Untertypenüberprüfungen können somit
die Geschwindigkeit, in der das Programm abläuft, beeinträchtigen.
-
Wenn
die Untertypen während
der Ausführung
eines Programms überprüft werden,
müssen
im wesentlichen alle Klassen und Verfahren, die mit dem Programm
verbunden sind, bekannt sein. Die Datenstrukturen sind oft so ausgeführt, dass
sie alle Klassen und Verfahren, die mit dem Programm verbunden sind,
auflisten, sodaß auf
die Klassen und Verfahren einfach zugegriffen werden kann. Mit andern Worten
müssen
die Datenstrukturen, die in den Untertypenüberprüfungen verwendet werden, oft
vor der Programmausführung
gerechnet werden. Solche Datenstrukturen sind oft relativ groß und verbrauchen
die Systemressourcen in signifikantem Ausmaß. Die Anforderung, dass alle
Klassen und Verfahren in Verbindung mit einem Programm bekannt sein müssen, verträgt sich
nicht mit Systemen, die eine dynamische Verbindung oder ein dynamisches
Laden einer Klasse nutzen, da die dynamische Verbindung es ermöglicht,
dass sich die Klassen und Verfahren in Verbindung mit dem Programm
effektiv ändern.
Die Leistung eines Programms kann auch bedeuten, dass es nicht zur
Nutzung einer dynamischen Verbindung befähigt ist. In einer Umgebung, die
eine dynamische Verbindung verwendet, werden die Datenstrukturen
im allgemeinen nach jeder Operation, die das Laden einer Klasse
beinhaltet, erneut berechnet, was zeitaufwendig und somit ineffizient ist.
-
Dave
Harris Scorp@binternet.com Newsgroup message XP02234507 kommentiert
die schnellen Instruktionen in der Java Virtual Machine. Die Java
Virtual Machine (JVM) stellt fest, dass eine Schnittstelle eine
Funktion hat, die eine ganze Zahl ist. JVM wandelt die Funktion,
die als Zeichenkette gespeichert ist, in einen vtbl-Index oder einen ähnlichen
Index um, und die rasche Instruktion nimmt das Ergebnis in den Cache-Speicher
auf.
-
Es
ist daher ein Verfahren und eine Vorrichtung zur Verbesserung der
Effektivität
erwünscht,
mit der Untertypenüberprüfungen vorgenommen
werden können.
Insbesondere ist ein Verfahren eine Vorrichtung zur effizienten
Durchführung
von Untertypenüberprüfungen erwünscht, ohne
dass es erforderlich ist, dass Datenstrukturen jedes Mal erneut
berechnet werden müssen,
wenn die Operation des Ladens einer Klasse erfolgt.
-
Verfahren
und Vorrichtungen zur Durchführung
schneller Überprüfungen von
Untertypen während
der Ausführung
des Programms sind offenbart. Die vorliegende Erfindung gibt daher
in einem Aspekt ein computerimplementiertes Verfahren zur Bestimmung
an, ob eine Klasse, die mit einem Objekt verbunden ist, welches
Teil eines auf dem Objekt beruhenden Rechensystems ist, ein Untertyp
eines anderen Typs ist, wobei das Objekt das Objekt eines ersten
Typs ist, und das Verfahren die Schritte umfaßt: Gewinnung eines zweiten
Typs, wobei der zweite Typ ein bezüglich des Objekts zu prüfender Typ
ist, Vergleichen des ersten Typs mit dem zweiten Typ, Feststellung,
ob der zweite Typ dem ersten Typ gleicht, Speicherung von Informationen
in Verbindung mit dem zweiten Typ in einem dynamischen Speicherplatz,
der mit der Klasse verbunden ist, die mit dem Objekt verbunden ist,
wenn festgestellt wurde, daß der
zweite Typ dem ersten Typ gleicht, wobei die Speicherung der Informationen
im dynamischen Speicherplatz ermöglicht,
dass auf die Informationen für
die nachfolgende Typenüberprüfung zugegriffen wird,
Durchführung
einer nachfolgenden Typenüberprüfung mit
den folgenden Schritten: Gewinnung eines zweiten zu prüfenden Typs,
der aus dem dynamischen Speicherplatz erhalten wurde, der mit der Klasse
verbunden ist, die mit dem Objekt verbunden ist, Vergleich des zweiten
zu prüfenden
Typs mit einem dritten Typ, Feststellung, ob der zweite zu prüfende Typ
dem dritten Typ im wesentlichen gleicht, und Vorsehen einer Anzeige,
dass der zweite zu prüfende
Typ eine Untergruppe des dritten Typs ist, wenn festgestellt wurde,
dass der zweite zu prüfende Typ
gleich dem dritten Typ ist.
-
In
einem zweiten Aspekt gibt die Erfindung ein Computersystem an, welches
so ausgelegt ist, dass es festlegt, ob eine Klasse, die mit einem
Objekt verbunden ist, welches im Computersystem vorhanden ist, ein
Untertyp eines anderen Typs ist, wobei das Objekt ein Objekt eines
ersten Typs ist und das Computersystem umfaßt: einen Prozessor und eine Speichervorrichtung,
die mit dem Prozessor kommuniziert und einen Computerprogramm-Code
speichert, und die so ausgelegt sind, dass sie
einen zweiten
Typ gewinnen, wobei der zweite Typ ein bezüglich des Objekts zu prüfender Typ
ist, den ersten Typ mit dem zweiten Typ vergleichen, feststellen,
ob der zweite Typ dem ersten Typ gleicht, Informationen in Verbindung
mit dem zweiten Typ in einem dynamischen Speicherplatz speichern,
der mit der Klasse verbunden ist, die mit dem Objekt verbunden ist,
wenn festgestellt wird, dass der zweite Typ dem ersten Typ gleicht,
wobei die Speicherung der Informationen im dynamischen Speicherplatz
ermöglicht,
dass auf die Informationen für
die nachfolgende Typenüberprüfung zugegriffen
wird,
eine nachfolgende Typenüberprüfung durchführen, welche die folgenden
Schritte umfaßt:
Gewinnung
eines zweiten zu prüfenden
Typs, wobei der zweite zu prüfende
Typ aus dem dynamischen Speicherplatz, der mit der Klasse verbunden
ist, die mit dem Objekt verbunden ist, erhalten wird,
Vergleich
des zweiten zu prüfenden
Typs mit einem dritten Typ,
Feststellung, ob der zweite zu
prüfende
Typ gleich dem dritten Typ ist, und
Vorsehen einer Anzeige,
dass der zweite zu prüfende Typ
eine Untergruppe des dritten Typs ist, wenn festgestellt wird, dass
der zweite zu prüfende
Typ dem dritten Typ gleicht.
-
In
einem dritten Aspekt gibt die Erfindung einen Computerprogramm-Code
an, der einen Satz von Instruktionen umfaßt, die dazu führen, wenn
sie auf einem Computer ausgeführt
werden, dass der Computer das Verfahren der Erfindung ausführt.
-
In
einem vierten Aspekt gibt die Erfindung ein Computerprogrammprodukt
an, das ein computerlesbares Medium umfaßt, welches den Computerprogramm-Code
der Erfindung enthält.
-
Die
vorliegende Erfindung kann anhand der folgenden detaillierten Beschreibungen
unter Bezug auf die verschiedenen Figuren der Zeichnungen besser
verstanden werden.
-
In
den speziellen Ausführungsformen
wird die vorliegende Erfindung unter Bezug auf die folgende Beschreibung
in Verbindung mit den beigefügten Zeichnungen
verständlich,
in denen zeigen:
-
1 eine
schematische Darstellung einer herkömmlichen Klassenhierarchie,
-
2a ein
Flußdiagramm
des Prozesses, welches die Schritte in Verbindung mit der Bestimmung
illustriert, ob ein Objekt ein Untertyp eines bestimmten Typs gemäß einer
Ausführungsform
der vorliegenden Erfindung ist,
-
2b ein
Flußdiagramm
des Prozesses, welches die Schritte in Verbindung mit einem Vergleich
eines Typs mit einem geladenen Cache illustriert, d.h., Schritt 208 von 2a,
gemäß einer
Ausführungsform
der vorliegenden Erfindung,
-
2c eine
schematische Darstellung einer Klasse mit einem Cache-Element gemäß einer
Ausführungsform
der vorliegenden Erfindung,
-
3 eine
schematische Darstellung eines Computersystems, das für die Realisierung
der vorliegenden Erfindung geeignet ist,
-
4 eine
schematische Darstellung einer virtuellen Maschine gemäß einer
Ausführungsform der
vorliegenden Erfindung.
-
Beschreibung der speziellen
Ausführungsformen
im Einzelnen
-
Im
allgemeinen erfordern Untertypenüberprüfungen,
die durchgeführt
werden, um eine Untertypenbeziehung zwischen Objekten zu bestimmen, eine
beträchtliche
Menge Speicherplatz eines Computers. Der Platz wird für die Instruktionen
in Verbindung mit der Durchführung
der Untertypenüberprüfungen,
sowie für
die vorausberechneten Datenstrukturen benötigt, die oft verwendet werden,
um alle Typen und Verfahren zu speichern, die mit der Ausführung eines
Computerprogramms verbunden sind. Zusätzlich zu den allgemeinen Unkosten,
die erforderlich sind, um wiederholte Untertypenüberprüfungen durchzuführen, beeinträchtigt der
für die Untertypenüberprüfungen benötigte Platz
oft die Geschwindigkeit, in der ein Programm ausgeführt wird.
-
Indem
man sich die erwarteten Ergebnisse der Untertypenüberprüfungen spart,
lassen sich die allgemeinen Unkosten in Verbindung mit der Durchführung der
Untertypenüberprüfungen effektiv
verringern. Insbesondere, wie dem Fachmann auf diesem Gebiet bewußt ist,
kann in der Laufzeit, das erste Mal, wo ein mit einem Objekt verknüpfter Untertyp bezüglich eines
speziellen Typs überprüft wird,
diese Überprüfung erfolgen,
indem im Wesentlichen jedes beliebige Verfahren angewendet wird.
Da die nachfolgenden Überprüfungen eines
Objekts der gleichen Klasse wahrscheinlich, außer dem Ergebnis der aktuellen Überprüfung, das
gleiche Untertypenergebnis, beispielsweise das Rechenergebnis der
ersten Überprüfung, haben,
könnte
so ermöglicht
werden, dass sich die allgemeinen Unkosten in Verbindung mit der
Durchführung
der Untertypenüberprüfungen wesentlich
verringern. Mit anderen Worten, ein Mechanismus einer dynamischen
Untertypenüberprüfung, der
die Cache-Speicherung
nutzt, macht es möglich,
dass Ergebnisse früherer
Untertypenüberprüfungen in
den Cache-Speicher aufgenommen werden, um die gleichen Überprüfungen zu
beschleunigen, falls nachfolgend die gleichen Überprüfungen durchgeführt werden,
indem er ermöglicht, dass
die gespeicherten Werte verwendet werden, wenn die gespeicherten
Werte als korrekt, d.h. zutreffend, bestimmt wurden. In einer Ausführungsform können die
im Cache gespeicherten Daten in einem Typen-Deskriptor des Wertes
gehalten werden, z.B. dem zu testenden oder zu überprüfenden Objekt.
-
Nach
einer Eingangsüberprüfung zur
Bestimmung des Untertyps eines Objektes "s",
das mit einer Klasse verbunden ist, werden die Ergebnisse der Eingangsüberprüfung gespeichert.
Durch die Speicherung der Ergebnisse der Eingangsüberprüfung des
Untertypen, ermöglichen
es die gespeicherten Ergebnisse das nächste Mal, wenn eine Überprüfung zur
Bestimmung des Untertypen des Objektes "s" erforderlich
ist, dass die gleiche Untertypenprüfung schneller durchgeführt wird.
Wenn beispielsweise der Untertyp des Objekts "s",
bezogen auf einen Typ "T" überprüft wird, d.h., wenn eine Bestimmung hinsichtlich
der Frage gemacht werden muß,
ob das Objekt "s" ein spezieller Untertyp "T" ist, ist ein relativ rascher Vergleich
zwischen dem gespeicherten Typen-Deskriptor
in Verbindung mit dem Objekt "s" und dem Untertypen "T" möglich.
Ist der Typ des Objekts "s" gleich dem Untertyp "T", wird der Vergleich als erfolgreich
angesehen und eine herkömmliche
Untertypenüberprüfung ist
im allgemeinen nicht erforderlich. Somit können die allgemeinen Kosten
in Verbindung mit einer herkömmlichen
Untertypenüberprüfung eingespart
werden. Alternativ dazu, wenn der Typ des Objekts "s" nicht gleich dem Untertyp "T" ist, kann eine herkömmliche Untertypenüberprüfung angewendet
werden, um den Typ des Objekts "s" zu bestimmen. In
einigen Fällen
kann eine solche Überprüfung das
Durchlaufen einer Klassenhierarchie, um den geeigneten Untertyp
zu finden, und das Auslösen
einer Ausnahme (raise an exception) mit einschließen, wenn
ein geeigneter Untertyp nicht gefunden werden kann.
-
Unter
Bezugnahme auf 2a sind die Schritte in Verbindung
mit der Bestimmung, ob ein Objekt ein Untertyp oder eine Unterklasse
eines bestimmten Typs ist, in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung beschrieben. Insbesondere ist ein Verfahren
für eine
Bestimmung beschrieben, ob ein Objekt ein Untertyp eines Typs "B" ist. Ein Verfahren 202 für eine Bestimmung, ob
ein Objekt ein Untertyp von Typ "B" ist, beginnt im Schritt 204,
in dem der Typ, z.B. die Klasse, des Objektes in ein Register geladen
wird, das mit einem Computersystem verbunden ist. Wie dem Fachmann auf
diesem Gebiet bekannt sein wird, ist die Gesamtklasse, z.B. eine
abstrakte Klasse, des Objekts bekannt. Wenn die Klasse des Objektes
in das Register geladen wurde, wird im Schritt 206 das
Cache-Element der geladenen Klasse geladen, es wird beispielsweise
in den Computerspeicher geladen. Das Cache-Element oder Cache ist
im folgenden unter Bezug auf 2c beschrieben.
-
Nachdem
das Cache geladen ist, wird der Typ B im Schritt 208 mit
dem geladenen Cache verglichen. Die Schritte in Verbindung mit dem
Vergleich des Typs B mit dem geladenen Cache sind im folgenden unter
Bezug auf die 2b beschrieben. Im Schritt 210 werden
die Ergebnisse des Vergleichs von Typ B gegenüber dem geladenen Cache bestimmt.
In der beschriebenen Ausführungsform
wird im Schritt 222 ein wahrer Wert an die Funktion zurückgesandt,
die gefordert hat, dass eine Bestimmung, ob das Objekt ein Untertyp
von B ist erfolgen soll, wenn der Vergleich des Typs B mit dem geladenen
Cache zu einem wahren Ergebnis führt,
d.h., wenn im Vergleich festgestellt wird, dass der Typ B und der
geladene Cache übereinstimmen.
Mit anderen Worten wird im Schritt 222 ein wahrer Wert
zurückgesandt,
wenn die geladene Klasse und Typ B die gleiche Klasse sind, oder
wenn die geladene Klasse ein Untertyp des Typs B ist. Ist der Wert 'wahr' zurückgesandt,
ist der Prozeß zur
Bestimmung, ob ein Objekt ein Untertyp des Typs B ist, abgeschlossen.
-
Wenn,
alternativ dazu, im Schritt 210 festgestellt wird, dass
der Vergleich des Typs B mit dem geladenen Cache nicht zu einem
wahren Ergebnis führt,
dann wird im Schritt 212 die Untertypenbeziehung zwischen
der Klasse des Objekts und dem Typ B berechnet. Das bedeutet, wenn
festgestellt wurde, dass die Klasse des Objektes und der Typ B nicht gleich
sind, erfolgt eine Berechnung, um die Beziehung, falls vorhanden,
zwischen der Klasse des Objekts und dem Typ B zu bestimmen. Nachdem
die Untertypenbeziehung berechnet wurde, wird bei Schritt 214 fortgefahren,
in welchem festgestellt wird, ob die Berechnung eines Untertyps
zu einem wahren Ergebnis führt,
d.h., ob es eine gültige
Untertypenbeziehung zwischen der Klasse des Objekts und dem Typ
B gibt.
-
Wird
im Schritt 214 bestimmt, dass es keine Untertypenbeziehung
zwischen der Klasse des Objekts und dem Typ B gibt, wird im Schritt 220 der
Wert 'falsch' zu der Funktion
zurückgesandt,
die die Untertypenüberprüfung gefordert
hat. Wenn der Wert 'falsch' zurückgesandt
wird, ist der Prozeß der
Bestimmung, ob ein Objekt ein Untertyp des Typs B ist, abgeschlossen.
Wird aber im Schritt 214 bestimmt, dass es eine Untertypenbeziehung
zwischen der Klasse des Objekts und dem Typ B gibt, wird der Prozeß im Schritt 216 fortgesetzt,
in welchem der Cache der Klasse des Objekts mit der Klasse B "gefüllt" wird. Mit anderen
Worten wird die Klasse B oder eine Referenz zum Typ B im Cache-Element
der Klasse des Objekts gespeichert. Nachdem der Cache der Klasse
des Objektes mit dem Typ B gefüllt
wurde, wird im Schritt 218 an das System ein Wert "wahr" zurückgesandt,
um anzuzeigen, dass es eine Untertypenbeziehung zwischen der Klasse
des Objekts und dem Typ B gibt. Der Prozeß der Bestimmung, ob ein Objekt
ein Untertyp des Typs B ist, ist damit abgeschlossen.
-
Unter
Bezugnahme auf die 2b sind die Schritte in Verbindung
mit einem Vergleich des Typs B und einem geladenen Cache, z.B. einer
Klasse eines bestimmten Objekts in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung beschrieben. Das heißt, es ist eine Ausführungsform von
Schritt 208 der 2a beschrieben.
Ein Vergleich des Typs B mit dem geladenen Cache beginnt in Schritt 232,
wo das Cache-Element in ein Register geladen wird. Insbesondere
wird das Cache-Element der
Klasse des Objekts, das im folgenden unter Bezug auf 2c beschrieben
ist, in ein Register geladen. Nachdem es im Register geladen ist,
wird im Schritt 234 der Inhalt des Registers mit dem Typ
B verglichen. Wie oben beschrieben, ermöglicht es ein Prüfmechanismus,
welcher die Cache-Speicherung verwendet, dass die Ergebnisse früherer Untertypenüberprüfungen im
Cache gespeichert werden, um die gleichen Überprüfungen zu beschleunigen, wenn
die gleichen Überprüfungen nachfolgend
durchgeführt werden,
wodurch die gespeicherten Werte verwendet werden können. Indem
ein im Cache gespeichertes Element bei der Prüfung verwendet werden kann, läßt sich
auf dieses Element einfach zugreifen. Im Wesentlichen kann jedes
beliebige geeignete Verfahren angewandt werden, um das Cache-Element mit dem Inhalt
des Registers zu vergleichen. Derartige Verfahren sind den Fachleuten
auf diesem Gebiet wohlbekannt. Wenn der Inhalt des Registers mit
dem Typ B verglichen wurde, ist der Prozeß des Vergleichs des Typs B
mit dem geladenen Cache abgeschlossen.
-
Wie
oben beschrieben, enthält
eine Klasse, z.B. ein Klassenobjekt, ein Cache-Element, in welches
das Ergebnis einer früheren
Untertypenüberprüfung gespeichert
werden kann. 2c ist eine schematische Darstellung
einer Klasse mit einem Cache-Element in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung. Ein Objekt "S" 252 enthält einen
Anfangsblock 256 und weist einen Klassen-Pointer zu einer
Klasse 260 auf. Die Klasse 260 enthält einen
Anfangsblock 264 und ein Cache-Element 268. Das
Cache-Element 268 ist,
wie oben erwähnt,
so ausgelegt, dass es das Ergebnis einer früheren, z.B. der ersten, Untertypenüberprüfung in
Verbindung mit der Klasse 260 speichert. Es ist anzumerken,
dass das Cache-Element 268, wenn die Klasse 260 voreingestellt
ist, im allgemeinen auf jeden Wert voreingestellt werden kann. So
kann das das Cache-Element 268 beispielsweise voreingestellt
werden, die Klasse 260 zu erkennen. Das Cache-Element 268 kann
im allgemeinen als "dynamisches" Speicherelement
betrachtet werden, da das Ergebnis, das im Cache-Element 268 gespeichert
ist, sich mit der Ausführung
des Programms oder, genauer, wenn die Untertypenüberprüfungen durchgeführt werden, ändern kann.
Das heißt,
der Inhalt des Cache-Elements 268 kann aktualisiert werden.
-
Wenn
das Objekt "s" 252 während einer
Untertypenüberprüfung, die
das Objekt "s" 252 einbezieht,
als ein Mitglied der Klasse 260 bekannt ist, kann auf das
Cache-Element 268 zugegriffen werden, um die Ergebnisse
der jüngsten
Untertypenüberprüfung, die
die Klasse 260 mit einbezieht, zu erhalten. Das Cache-Element 268 kann
im allgemeinen aktualisiert werden, um die Ergebnisse der jüngsten Untertypenüberprüfung, die
die Klasse 260 mit einbezieht, zu speichern. Als solche
können
in dem Fall, dass das im Cache-Element 268 gespeicherte
Ergebnis nicht der mit dem Objekt "s" 252 verbundene Untertyp
ist, dann der aktuelle, mit dem Objekt "s" 252 verbundene
Untertyp, einmal bestimmt, im Cache-Element 268 gespeichert
werden. Es ist zu beachten, dass in einigen Ausführungsformen die Speicherung
und auch die Wiedergewinnung der Informationen aus dem Cache-Element 268 eine
Synchronisierung bedingen kann, um eventuell auftretenden Stimmigkeitsproblemen
zu begegnen.
-
3 zeigt
ein typisches Universal-Computersystem, welches zur Realisierung
der vorliegenden Erfindung geeignet ist. Ein Computersystem 330 enthält eine
beliebige Anzahl Prozessoren 332, die auch Zentralprozessoreinheiten
(CPU) genannt werden, und die mit Speichergeräten gekoppelt sind. Die Speichergeräte sind
im allgemeinen Primärspeichergeräte 334,
wie beispielsweise ein Direktzugriffsspeicher (RAM), und Primärspeichergeräte 336,
wie beispielsweise ein Nur-Lese-Speicher
(ROM).
-
Das
Computersystem 330 oder, genauer, die Zentralprozessoreinheiten 332,
können
so ausgeführt
sein, dass sie eine virtuelle Maschine unterstützen, wie sie den Fachleuten
auf diesem Gebiet bekannt ist. Ein Beispiel einer solchen virtuellen
Maschine, die vom Computersystem 330 unterstützt wird,
ist im Folgenden unter Bezug auf 4 beschrieben.
Wie auf diesem Gebiet bekannt, dient der ROM 334 dazu,
Daten und Instruktionen in einer Richtung zu den Zentralprozessoreinheiten 332 zu übertragen,
während
der Direktzugriffsspeicher 336 typischerweise verwendet
wird, um Daten und Instruktionen zu und von den Zentralprozessoreinheiten 332 bidirektional
zu übertragen.
Beide Primärspeichergeräte 334, 336 können im
Wesentlichen beliebige geeignete computerlesbare Medien sein. Ein sekundäres Speichermedium 338,
welches typischerweise ein Massenspeicher ist, kann ebenfalls bidirektional
mit den Zentralprozessoreinheiten 332 gekoppelt sein.
-
Im
allgemeinen ist das sekundäre
Speichermedium 338 so ausgeführt, dass es zusätzliche
Datenspeicherkapazitäten
bietet, und es kann ein computerlesbares Medium sein, das zur Speicherung
von Programmen, z.B. eines Computer-Codes, von Computerprogramm-Codegeräten, Daten
und dergleichen, verwendet wird. Das sekundäre Speichermedium 338 ist
typischerweise ein Speichermedium, wie z.B. eine Harddisk oder ein
Band, welches langsamer als die Primärspeichergeräte 334, 336 sein
kann. Das sekundäre
Speichermedium 338 kann die Form einer sehr bekannten Vorrichtung
haben, wie z.B. Magnetband- und Lochstreifenleser, ist aber nicht
auf diese beschränkt.
Wie den Fachleuten auf diesem Gebiet einleuchtend sein wird, können die
im sekundären
Speichermedium 338 gehaltenen Informationen in geeigneten
Fällen
in einer dem Standard entsprechenden Weise als Teil des Direktzugriffsspeichers 336,
z.B. als virtueller Speicher, eingebaut werden. Ein spezifisches
Primärspeichergerät 334,
beispielsweise eine CD-ROM, kann auch Daten unidirektional an die
Zentralprozessoreinheiten 332 weiterleiten.
-
Die
Zentralprozessoreinheiten 332 sind ferner mit einer oder
mehreren Eingabe/Ausgabe-Geräten 340 gekoppelt,
die Videomonitore, Rollkugeln, Mäuse,
Tastaturen, Mikrophone, berührungsempfindliche
Anzeigen, Transducer-Kartenleser,
Magnetband- oder Lochstreifenleser, Tafeln, Stylii, Sprach- oder
Handschriftenerkennungsgeräte,
sowie andere allgemein bekannte Eingabegeräte, beispielsweise andere Computer
sein können,
aber nicht darauf beschränkt
sind. Schließlich
können
die Zentralprozessoreinheiten 332 optional mit einem Computer-
oder einem Telekommunikationsnetzwerk gekoppelt sein, z.B. einem
Internet- oder Intranet-Netzwerk,
indem eine Netzwerkverbindung verwendet wird, wie allgemein in 312 angegeben.
Mit einer derartigen Netzwerkverbindung 312 wird berücksichtigt,
dass die Zentralprozessoreinheiten 332 Informationen aus
einem Netzwerk erhalten können.
Die Zentralprozessoreinheiten 332 können ebenfalls, im Laufe der Durchführung der
oben beschriebenen Verfahrensschritte, Informationen ins Netz ausgeben.
Solche Informationen, die oft als Sequenz von Instruktionen dargestellt
werden, die unter Verwendung der Zentralprozessoreinheiten 332 ausgeführt werden
müssen,
können
aus dem Netz empfangen und ins Netz ausgegeben werden, beispielsweise
in Form eines in einer Trägerwelle
enthaltenen Computerdatensignals. Die Fachleute auf dem Gebiet der
Computer-Hardware und der Software sind mit den oben beschriebenen
Geräten
und Materialien vertraut.
-
Wie
oben erwähnt,
kann eine virtuelle Maschine mit dem Computersystem 330 arbeiten. 4 ist
eine schematische Darstellung einer virtuellen Maschine, die vom
Computersystem 330 in 3 unterstützt wird
und die zur Realisierung der vorliegenden Erfindung geeignet ist.
Wenn ein Computerprogramm, z.B. ein in der Programmiersprache JavaTM geschriebenes Computerprogramm, ausgeführt wird,
wird innerhalb der Kompilierzeit-Umgebung 405 ein
Quellencode 410 an einen Kompilierer 420 geliefert.
Der Kompilierer 420 übersetzt
den Quellencode 410 in Bytecodes 430. Der Quellencode 410 wird
im allgemeinen zu der Zeit in Bytecodes 430 übersetzt, in
der er von einem Software-Entwickler erstellt wird.
-
Die
Bytecodes 430 können
im allgemeinen reproduziert, heruntergeladen oder in anderer Weise in
einem Netzwerk, beispielsweise dem Netzwerk 312 von 3,
verteilt oder in einem Speichergerät, beispielsweise dem Primärspeicher 334 von 3, gespeichert
werden. In der beschriebenen Ausführungsform sind die Bytecodes 430 von
der Plattform unabhängig.
Das heißt,
die Bytecodes 430 können
im Wesentlichen auf jedem Computersystem ausgeführt werden, das auf einer geeigneten
virtuellen Maschine 440 läuft.
-
Die
Bytecodes 430 werden einer Laufzeit-Umgebung 435 geliefert,
die die virtuelle Maschine 440 enthält. In einer Ausführungsform
kann die virtuelle Maschine eine virtuelle JavaTM-Maschine sein.
Die Laufzeit-Umgebung 435 kann im allgemeinen mit einem
Prozessor oder mit Prozessoren, beispielsweise den Zentralprozessoreinheiten 332 von 3 arbeiten.
Die virtuelle Maschine 440 enthält einen Kompilierer 442,
einen Interpretierer 444 und ein Laufzeitsystem 446.
Die Bytecodes 430 können
entweder an den Kompilierer 442 oder den Interpretierer 444 übertragen
werden.
-
Wenn
die Bytecodes 430 an den Kompilierer 442 übertragen
werden, werden die in den Bytecodes 430 enthaltenen Verfahren
in Maschineninstruktionen übersetzt.
In einer Ausführungsform
ist der Kompilierer 442 ein "Just-in-time"-Kompilierer,
welcher die Übersetzung
von Verfahren, die in den Bytecodes 430 enthalten sind,
solange verzögert,
bis die Verfahren ausgeführt
werden sollen. Wenn die Bytecodes 430 dem Interpretierer 444 übertragen
werden, wird ein Bytecode nach dem anderen in den Interpretierer eingelesen.
Der Interpretierer 444 führt dann die Operation aus,
die von jedem Bytecode vorgegeben wird, wenn jeder Bytecode in den
Interpretierer 444 eingelesen wird. Das heißt, der
Interpretierer 444 "interpretiert" die Bytecodes 430,
wie den Fachleuten auf diesem Gebiet verständlich ist. Im Allgemeinen verarbeitet
der Interpretierer 444 die Bytecodes 430 und führt im Wesentlichen
kontinuierlich Operationen durch, die mit den Bytecodes 430 verbunden
sind.
-
Wenn
ein Verfahren durch ein anderes Verfahren oder von der Laufzeit-Umgebung 435 aufgerufen
wird und das Verfahren interpretiert wird, kann das Laufzeitsystem 446 das
Verfahren von der Laufzeit-Umgebung 435 in Form einer Sequenz
von Bytecodes 430 erhalten, welche direkt vom Interpretierer 444 ausgeführt werden
können.
Wenn andererseits das Verfahren, das aufgerufen wird, ein zu kompilierendes
Verfahren ist, das noch nicht kompiliert wurde, erhält das Laufzeitsystem 446 ebenfalls
das Verfahren von der Laufzeit-Umgebung 435 in Form einer Sequenz
von Bytecodes 430, wonach es dann den Kompilierer 442 aktivieren
kann. Der Kompilierer 442 erzeugt dann Maschineninstruktionen
aus den Bytecodes 430, und die sich ergebenden Instruktionen
in Maschinesprache können
direkt von den Zentralprozessoreinheiten 332 von 3 ausgeführt werden. Im
allgemeinen werden die Instruktionen in Maschinesprache verworfen,
wenn die virtuelle Maschine 440 aufhört.
-
Obwohl
nur einige wenige Ausführungsformen
der vorliegenden Erfindung beschrieben worden sind, ist es selbstverständlich,
dass die vorliegende Erfindung in vielen anderen Formen realisiert
werden kann, ohne dass vom Wesen oder Umfang der vorliegenden Erfindung
abgewichen wird. Beispielsweise kann in einigen Ausführungsformen
ein Klassenobjekt mehr als ein Cache-Element enthalten. Wenn ein Klassenobjekt
mehr als ein Cache-Element enthält, können mehr
Ergebnisse als nur ein früheres
Ergebnis einer Untertypenüberprüfung gespeichert
werden. Das heißt,
es können
mehr als nur ein wahrscheinlicher Untertyp für ein Objekt gespeichert werden,
so dass bei der Feststellung, dass der in einem Cache-Element gespeicherte
Untertyp nicht der Untertyp für
das Objekt ist, der in einem andern Cache-Element gespeicherte Untertyp
geprüft
werden kann.
-
Die
vorliegende Erfindung wurde im Hinblick auf die Speicherung eines
früheren
Ergebnisses einer Untertypenüberprüfung in
einem Cache-Element einer Klasse beschrieben, es ist aber anzumerken, dass
die früheren
Ergebnisse nicht notwendigerweise im Cache-Element gespeichert werden. Die früheren Ergebnisse
können
stattdessen während
einer Untertypenüberprüfung in
jedem beliebigen Speicherplatz gespeichert werden, auf den ein Zugriff möglich ist.
So können
beispielsweise die Ergebnisse einer früheren Untertypenüberprüfung in
einem Abschnitt des Computercodes gespeichert werden, der nicht
direkt mit der Klasse verbunden ist. Alternativ dazu können die
Ergebnisse einer früheren
Untertypenüberprüfung in
einer dynamischen Tabelle mit globalem Zugriff gespeichert werden,
auf die jedes Mal zugegriffen wird, wenn eine Untertypenüberprüfung erfolgt,
die eine bestimmte Klasse einbezieht. Eine derartige Tabelle kann
mit der bestimmten Klasse direkt verbunden sein.
-
Es
versteht sich von selbst, dass in einer Ausführungsform, anstelle der Durchführung einer Überprüfung zur
Feststellung, ob ein bestimmtes Objekt zu einem bestimmten Untertypen
gehört,
auch eine Überprüfung zur
Feststellung erfolgen kann, daß ein
bestimmtes Objekt nicht zu einem bestimmten Untertypen gehört. Die
Ergebnisse einer derartigen Überprüfung können im
allgemeinen in einem Cache-Element einer Klasse in einem Segment
des Computercodes oder als Teil einer globalen Tabelle gespeichert
werden. Ein Cache-Element
kann mit anderen Worten so ausgeführt sein, dass es eine Untertypenbezeichnung
enthält,
die wahrscheinlich nicht zu einer bestimmten Untertypenüberprüfung paßt.
-
Die
Instruktionen oder Operationen, die Untertypenüberprüfungen verwenden, können in
Abhängigkeit
von den Anforderungen eines bestimmten Systems in einem großen Ausmaß variiert
werden. So nutzen beispielsweise eine "aastore"-Instruktion, eine "checkcast"-Instruktion und eine "instanceof"-Instruktion in einer JavaTM-Umgebung
generell Untertypenüberprüfungen.
-
Außerdem können auch
die Schritte in Verbindung mit der Durchführung einer Untertypenüberprüfung gemäß der vorliegenden
Erfindung variieren. So kann beispielsweise die Festlegung, Vergleiche und
Rechenergebnisse mit "wahr" zu bezeichnen, stattdessen
die Festlegung sein, Vergleiche und Rechenergebnisse mit "falsch" zu bezeichnen. Wenn
alternativ dazu ein Klassenobjekt mehr als ein Cache-Element enthält, können die
mit der Durchführung
einer Untertypenüberprüfung verbundenen Schritte
Schritte sein, die effektiv durch jedes Cache-Element schleifen, bis entweder eine
Untertypenübereinstimmung
gefunden ist oder alle Cache-Elemente
getestet wurden. Daher sind die vorliegenden Beispiele lediglich
als eine Illustration und nicht als eine Einschränkung anzusehen und die Erfindung
ist nicht auf die hier angegebenen Einzelheiten beschränkt, sondern
ist durch die folgenden Ansprüche
definiert.