DE60103521T2

DE60103521T2 - Vorladen von klassen in einer datenverarbeitungseinrichtung ohne virtueller speicherverwalter

Info

Publication number: DE60103521T2
Application number: DE60103521T
Authority: DE
Inventors: N. Frank YELLIN
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-03-09
Filing date: 2001-03-08
Publication date: 2005-06-23
Anticipated expiration: 2021-03-09
Also published as: CN1218245C; KR20030044902A; EP1269309A2; ATE268023T1; WO2001067236A3; AU4202801A; RU2002126996A; CA2402298A1; WO2001067236A2; US6745386B1; EP1269309B1; JP2003526154A; AU2001242028B2; DE60103521D1; CN1427968A

Description

Die vorliegende Erfindung betrifft allgemein Rechnersysteme und Vorrichtungen, welche in objektorientierten Rechnersprachen, wie etwa Java, geschriebene Programme ausführen, und betrifft im Besonderen ein System und ein Verfahren, um vorab einen Satz von Klassen in eine solchen Vorrichtung zu laden.
HINTERGRUND DER ERFINDUNG
In Rechnersystemen, welche Java-Programme oder andere Programme in anderen objektorientierten Sprachen ausführen, die eine Laufzeitprogrammverknüpfung unterstützen, wird der Satz an auszuführenden Rechnerprogrammen dynamisch bestimmt, geladen und bei Laufzeit verknüpft. Während dies sehr flexibel ist und es besonders einfach macht, von entfernt aufgestellten Rechnern aus geladene Software zu verwenden, kann das Laden und Verknüpfen eines Basissatzes von Klassendateien, welche benötigt werden, um Basisdatenverarbeitungsvorgänge zu unterstützen, zeitaufwändig und hinsichtlich SpeicherRessourcen aufwändig sein, insbesondere bei kleinen Clientvorrichtungen, deren Rechenleistung und SpeicherRessourcen viel stärker begrenzt ist als typische Desktoprechner.
Dieses Problem wird in dem U.S. Patent mit der Nummer 5,815,718 angegangen, welches am 09. September 1998 an Theron Tock ausgegeben und Sun Microsystems, Inc. übertragen wurde. Das '718 Patent ist insbesondere auf ein Vorabladen von Klassendateien in Nur-Lesespeicher (ROM = read only memory) fokussiert, und zwar zur Verwendung in Clientvorrichtungen mit sehr beschränkten Lese/SchreibspeicherRessourcen. Derartige Vorrichtungen verwenden ROM, um einen bedeutenden Teil ihrer Software zu speichern.
Die vorliegende Erfindung ist auf ein verwandtes, jedoch etwas anderes Problem gerichtet – auf ein Vorabladen von Klassendateien in eine Clientvorrichtung, welche keine Verwaltungseinrichtung zum Verwalten von virtuellem Speicher (virual memory manager) aufweist. Ein weiteres Problem, welches durch die vorliegende Erfindung angegangen wird, ist, wie die Datenstrukturen einer virtuellen Maschine (z.B. eine Java-Programm-Verfizierungseinrichtung, Klassenladeeinrichtung, Interpretierer und zugeordnete Sicherheitsprozeduren) derart erneut anzuordnen sind, dass sie in einer Clientvorrichtung ausgeführt werden können, welche die maximale Größe einer beliebigen Datenstruktur begrenzt. Beispielsweise kann die maximale Größe einer Ressource 64K Byte betragen.
ABRISS DER ERFINDUNG
Ein Autorensystem präpariert einen spezifizierten Satz von Klassen zum Vorabladen in Clientvorrichtungen ohne eine Verwaltungseinrichtung für einen virtuellen Speicher. Das Autorensystem wandelt den spezifizierten Satz von Klassen in eine Mehrzahl von Ressourcenmodulen um, wobei ein Untersatz der Ressourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Ressourcenmodule aufweisen. Das Autorensystem erzeugt ein Lademodul zum Laden in die Clientvorrichtungen, welches die Mehrzahl von Ressourcenmodulen, einen Interpretierer und eine Hochfahrprozedur (Startup) enthält. Der Interpretierer dient zur Ausführung von Programmen in einer vordefinierten Computersprache an den Clientvorrichtungen. Der spezifizierte Satz von Klassen umfasst Methoden in der vordefinierten Rechnersprache. Die Hochfahrprozedur dient zur Ausführung durch die Clientvorrichtungen beim Laden des Interpretierers für eine Ausführung. Die Hochfahrprozedur ersetzt Zeiger in den Ressourcenmodulen mit aktualisierten Zeigern nach Maßgabe von tatsächlichen Speicherstellen der Ressourcenmodule in irgendeiner besonderen der Clientvorrichtungen.
Ein weiterer Gesichtspunkt der vorliegenden Erfindung ist eine Clientvorrich tung mit einer Datenverarbeitungseinheit, einer Nutzerschnittstelle und einem Speicher zum Speichern eines Betriebssystems, welchem eine Verwaltungseinrichtung zum Verwalten eines virtuellen Speichers fehlt, ebenso wie die zuvor genannten Ressourcenmodule, der Interpretierer und die Hochfahrprozedur.
In einer Ausführungsform der Erfindung umfassen die Ressourcenmodule ein KlassentabellenRessourcenmodul, ein MethodentabellenRessourcenmodul, ein FeldtabellenRessourcenmodul, ein KonstantenpoolRessourcenmodul und ein ZeichenkettenRessourcenmodul. Die Klassendatenstruktur umfasst Zeiger auf Posten in dem Methodentabellen-, dem Feldtabellen- und dem KonstantenpoolRessourcenmodul, das FeldtabellenRessourcenmodul umfasst Zeiger auf Posten in dem ZeichenkettenRessourcenmodul und das KonstantenpoolRessourcenmodul umfasst Zeiger auf Posten in dem FeldtabellenRessourcenmodul und auf Posten in dem ZeichenkettenRessourcenmodul.
In einer Ausführungsform der Erfindung umfasst die Hochfahrprozedur Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Ressourcenmodule in dem Untersatz bei einer 0 mod 4 Adresse mit irgendeiner besonderen der Clientvorrichtungen.
In einer Ausführungsform der Erfindung umfassen die Ressourcenmodule eine Tabelle mit Inhalten, welche eine Speicheradresse für jeden aus einem zweiten Untersatz der Ressourcenmodule bezeichnen, wobei der zweite Untersatz jene der Ressourcenmodule einschließt, auf welche wenigstens einer der Zeiger in den Ressourcenmodulen zeigt. Die Hochfahrprozedur umfasst Anweisungen für (A) eine Bestimmung einer momentanen Speicheradresse für jedes der Ressourcenmodule in dem zweiten Untersatz, eine Bestimmung eines Differenzenwerts für jedes Ressourcenmodul in dem zweiten Untersatz, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle bezeichneten Speicheradresse entspricht, sowie (B) zur Einstellung wenigstens eines Untersatzes der Zeiger in den Ressourcenmodulen nach Maßgabe der Differenzenwerte.
In einer Ausführungsform der Erfindung umfassen die Ressourcenmodule ein Methodentabellenmodul mit Zeigern auf einen Code für Methoden des spezifizierten Satzes von Klassen und ein Untersatz der Zeiger in der Methodentabelle zeigt auf Maschinenmethoden im kompilierten Interpretierer.
KURZE BESCHEIBUNG DER ZEICHNUNGEN
Zusätzliche Aufgaben und Merkmale der Erfindung werden aus der folgenden ausführlichen Beschreibung und den angehängten Ansprüchen in Zusammenschau mit den Zeichnungen einfacher deutlich. Es stellt dar:
1 ein Blockdiagramm eines Autorensystems einer Java Virtual Machine (JVM).
2 einen Block einer Clientvorrichtung, in welcher die JVM mit einem Satz von vorab geladenen Klassen ausgeführt wird.
3 ein Speicherkennfeld einer Clientvorrichtung.
4 eine Klassendatei-Datenstruktur.
5 ein Flussdiagramm des Prozesses zur Erzeugung eines Satzes von vorab geladenen Klassen zur Verwendung durch die JVM in einer Clientvorrichtung.
6 eine Maschinenmethodentabellendatenstruktur.
7 ein Lademodul, auch als ein Satz von Ressourcenmodulen bekannt.
8 eine Inhaltstabellendatenstruktur, welche Information über die Ressourcenmodule speichert.
9A eine UTF-Zeichenkettentabellendatenstruktur, und 9B und 9C eine Internierte-Zeichenketten-Tabellendatenstruktur.
10 und 11 eine Klassentabellendatenstruktur.
12 eine Methodentabellen-, eine Codeblock- und eine Ausnahmetabellendatenstruktur.
13 eine Feldtabellendatenstruktur.
14 eine Konstantenpool-Datenstruktur.
15 eine konzeptionelle Wiedergabe des Prozesses einer Einstellung des Ortes der ersten Datenstruktur in einer Ressource derart, dass sie auf eine 0 mod 4 Adresse fällt.
16A und 16B ein Flussdiagramm der JVM-Hochfahrprozedur.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Mit Verweis auf 1 und 2 ist dort ein verteiltes Rechnersystem 100 gezeigt mit Clientvorrichtungen 102, wenigstens einem Serverrechner 104, einem Autorensystem 106 und einem oder mehreren Kommunikationsnetzwerken oder Verbindungen 108, welche die verschiedenen Clientvorrichtungen 102, die Serverrechner 104 und das Autorensystem 106 verbinden. Die Clientvorrichtungen 102 können verschiedene Arten von Rechner und rechnergesteuerten Vorrichtungen umfassen, einschließlich von in der Hand gehaltenen Vorrichtungen, wie etwa Personal Digital Assistants (PDA's), eingebetteten Vorrichtungen, Deskotrechnern usw. Die Serverrechner 104 speichern Dokumente und herunterladbare Applets 110, auf welche durch die Clientvorrichtungen zugegriffen werden kann.
Das Kommunikationsnetzwerk oder die Verbindung 108 kann ganz einfach als ein serielles Kabel oder eine serielle Infrarotverbindung zwischen einem Server und einer Clientvorrichtung ausgebildet sein oder kann ein Local Area Network oder eine Internet-Netzwerkverbindung umfassen.
In einer bevorzugten Ausführungsform sind wenigstens einige der Clientvorrichtungen 102 derart konfiguriert, dass sie Java-Sprachprogramme und Applets (Java ist eine Marke von Sun Microsystems) unter Verwendung eines Programminterpretierers ausführen, welcher als die Java Virtual Machine (JVM) 112 bekannt ist (eine Marke von Sund Microsystems). Die JVM 112 ist in dieser Ausführungsform eine besondere Version der Java Virtual Machine (bisweilen als "KVM" bezeichnet, um anzuzeigen, dass sie zur Verwendung durch kleine Vorrichtungen gedacht ist), welche für eine Ausführung durch Clientvorrichtungen konstruiert ist, die nicht über eine Verwaltungseinrichtung zur Verwaltung eines virtuellen Speichers als Teil ihres Betriebssystems verfügen und welche darüber hinaus Größenbeschränkungen hinsichtlich der Menge an aktivem Speicher aufweisen, welcher durch irgendein ausführendes Programm verwendet werden kann.
Die Rolle des Autorensystems 106 ist es, einen Satz von vorab geladenen Klassendateien zur Verwendung in Clientvorrichtungen zu erzeugen, welche keine Verwaltungseinrichtung zur Verwaltung eines virtuellen Speichers als Teil ihres Betriebssystems aufweisen und welche darüber hinaus Größenbeschränkungen hinsichtlich der Menge an aktivem Speicher aufweisen, welcher durch irgendein ausführendes Programm verwendet werden kann. Für den Rest dieser Druckschrift wird der Ausdruck "Clientvorrichtungen" derart verwendet werden, dass er sich lediglich auf die Clientvorrichtungen bezieht, für welche das Autorensystem 106 einen Satz von vorab geladenen Klassen erzeugt. Andere Clientvorrichtungen sind nicht Gegenstand dieser Druckschrift.
Es ist weiterhin die Rolle des Autorensystems 106, eine JVM-Hochfahrprozedur 114 zu erzeugen, welche durch die Clientvorrichtungen immer dann ausgeführt werden soll, wenn die JVM geladen wird, um ein Java-Programm oder -Applet auszuführen.
Übersicht über ein JVM-Autorensystem
Das JVM-Autorensystem 106 kann eine typische Rechnerworkstation mit einer oder Datenverarbeitungseinheiten (CPUs) 120, einer Nutzerschnittstelle 122, einem Speicher 124, einer Netzwerkkommunikationsschnittstelle 126, um Kommunikationsvorgänge mit anderen Vorrichtungen über ein Netzwerk 108 zu ermöglichen, und einen oder mehrere interne Busse 128 aufweisen, um die verschiedenen Komponenten des Systems 106 miteinander zu verbinden. Der Speicher 124 umfasst typischerweise einen Hochgeschwindigkeits-Random Accesss-Speicher (RAM = Random Access Memory) und einen nicht flüchtigen Speicher, wie etwa eine Festplattenspeichervorrichtung.
In einer bevorzugten Ausführungsform speichert der Speicher 124:

– einen Satz von Betriebssystemprozeduren 130 zur Ausführung von Systembasisfunktionen;
– Netzwerkzugriffs- oder Kommunikationsprozeduren 132 zur Handhabung von Kommunikationsvorgänge mit anderen Rechnern und Vorrichtungen; (wie oben angezeigt, kann dies eine einfache serielle Verbindungskommunikationsprozedur sein oder kann eine vollständige Netzwerkkonnektivitätsprozedur sein);
– ein Quellcodedepot 134 zum Speichern des Quellcodes für Prozeduren, einschließlich des Quellcodes 136 für die JVM und des Quellcodes 138 für die JVM-Hochfahrprozedur;
– ein Klassendateidepot 140 zum Speichern von Java-Sprachprogrammen, einschließlich Klassendateien 142 und Klassenbibliotheken 144;
– eine Offline-Klassenladeeinrichtung 150, welche eines der Werkzeuge ist, die in einer bevorzugten Ausführungsform der vorliegenden verwendet wird, um einen Satz von Klassendateien vorab in die Clientvorrichtungen zu laden, und insbesondere verwendet wird, um eine JVM-Offline-Klassendatei 152 zu erzeugen, welche ein Programm in der Sprache C enthält;
– einen lokalen Kompilierer 154, wie etwa einen C-Kompilierer, um die JVM-Offline-Klassendatei 152 in eine ausführbare Datei zu kompilieren;
– eine Programmausführungseinrichtung 156 zur Ausführung der durch den lokalen Kompilierer 154 erzeugten Datei, um einen Satz von Ressourcendateien 158 zu erzeugen, deren Natur unten ausführlicher erläutert werden wird;
– einen Clientvorrichtungskompilierer 160 zum Kompilieren von Programmen in eine für eine Ausführung als Maschinencode durch die Clientvorrichtungen geeignete Form;
– ein Lademodul 162 zum Laden in die Clientvorrichtungen 102; wobei das Lademodul einen Satz von Ressourcendateien enthält, welche einen Satz von vorab geladenen Klassendateien repräsentieren;
– ein kompiliertes JVM-Programm 164 zur Ausführung durch die Clientvorrichtungen; und
– ein kompiliertes JVM-Hochfahrprogramm 166 zur Ausführung durch die Clientvorrichtungen.

Der Ursprung, die Funktion und die Struktur zahlreicher der oben genannten Dateien und Programme wird weiter unten im Abschnitt dieser Druckschrift mit dem Titel "Prozess zur Erzeugung vorab geladener Klassendateien" ausführlicher beschrieben.
Übersicht über die Clientvorrichtung
Eine Clientvorrichtung 102 kann beispielsweise ein in der Hand gehaltener persönlicher digitaler Assistent (personal digital assistant) sein, wie etwa die Palm-Vorrichtungen (Palm ist eine Marke von 3COM), hergestellt durch 3COM (Palm Division) und andere Vorrichtungen, welche das PalmOS-Betriebssystem verwenden. Während es verschiedene Versionen des Palm gibt, welche sich hinsichtlich der Menge an bereitgestelltem Speicher unterscheiden, sind die grundlegenden Merkmale und Beschränkungen des hier beschriebenen Palm auf alle Versionen dieser Produktlinie ab dem ersten Quartal des Jahrs 2000 anwendbar.
Die Clientvorrichtung 102 wird typischerweise eine Datenverarbeitungseinheit (CPU) 220, eine Nutzerschnittstelle 222, einen Speicher 224, eine Kommunikationsschnittstelle 226 (wie etwa Netzwerk- oder serielle oder IR-Kommunikationsschnittstelle) aufweisen, um Kommunikationsvorgänge mit anderen Vorrichtungen (z.B. Servern 104) über ein Netzwerk oder ein anderes Kommunikationsmedium 108 zu ermöglichen, und wird einen oder mehrere interne Busse 228 aufweisen, um die verschiedenen Komponenten der Clientvorrichtung 102 miteinander zu verbinden. Der Speicher 224 umfasst typischerweise einen dynamischen Hochgeschwindigkeits-Random Access-Speicher (DRAM) und/oder statischen Random Access-Speicher.
In einer bevorzugten Ausführungsform speichert der Speicher 224:

– einen Satz von Betriebssystemprozeduren (z.B. das PalmOS) 230 zur Ausführung von Systembasisfunktionen;
– Netzwerkzugriffsprozeduren 232 zur Handhabung von Kommunikationsvorgängen mit anderen Rechnern und Vorrichtungen;
– das durch das JVM-Autorensystem erzeugte Lademodul 162;
– die Java Virtual Machine (JVM) 112, welche einen den Maschinencode der Clientvorrichtung kompiliertes Programm ist;
– das JVM-Hochfahrprogramm 114, welches verwendet wird, um die JVM auf eine Ausführung vorzubereiten und dem Fehlen einer Verwaltungseinrichtung zur Verwaltung virtuellen Speichers in der Clientvorrichtung abzuhelfen;
– JVM-Ressourcen 234, welche die vorab geladenen Klassendateien repräsentieren, die zur Ausführung durch die JVM bereit sind, ohne durch Klassenverifizierungs- und Ladeschritte gehen zu müssen;
– ein Klassendepot 240 zum Speichern von Java-Sprachprogrammen, einschließlich von von Servern 104 heruntergeladenen Klassendateien 242;
– eine Anwendung 252, welche die JVM 112 aufruft, etwa zur Ausführung eines Spielprogramms oder irgendeines anderen in der Java-Sprache geschriebenen Programmtyps;
– andere Anwendungsprogramme 254, wie etwa eine Adressbuchanwendung, eine Kalenderanwendung usw.;
– eine Programmausführungseinrichtung 256 zum Ausführen der JVM 112, der JVM-Hochfahrprozedur 114 und von Anwendungsprogrammen 252, 254; sowie
– Datendateien 270.

Die Anwendung 252 ist typischerweise nicht Teil des Lademoduls, welches die JVM und die JVM-Ressourcen umfasst. Dies bedeutet, Anwendungen 252, welche die JVM aufrufen, werden typischerweise gesondert in die Clientvorrichtung geladen.
Die Anwendung 252 kann in einigen Ausführungsformen eine Browseranwendung sein, welche Anweisungen enthält zum Herunterladen von HTML-Dokumenten 262 von entfernt aufgestellten Rechnern, wie etwa Servern 104, und welche in einem HTML-Dokumentendepot 260 im Speicher 224 gespeichert sind. Der Browser ist typischerweise eine in den Maschinencode der Clientvorrichtung kompilierte Anwendung. Jedoch könnte der Browser in einer alternativen Ausführungsform als ein Java Bytecode Programm implementiert sein, welches in den vorab geladenen Klassen im Lademodul 162 enthalten ist. Die heruntergeladenen Dokumente können Dokumente umfassen, die in sich eingebettet Verweise (z.B. HTML-Objekttags oder Applettags) auf Applets aufweisen, die durch die JVM 112 ausführbar sind. Ferner umfasst die Browseranwendung Anweisungen zur Anzeige der Dokumente, einschließlich irgendwelcher durch Ausführung des Applets oder von Applets darin erzeugten Bildern, an einer Anzeige in der Nutzerschnittstelle 222.
Prozess zum Erzeugen vorab geladener Klassendateien
3 zeigt ein Speicherkennfeld einer Clientvorrichtung. Wie gezeigt ist, ist ein erster Abschnitt 280 des Speichers der Vorrichtung für das Betriebssystem reserviert. Ein zweiter Abschnitt 282, welcher in dem Palm abhängig von der Version des PalmOS in der Vorrichtung eine Größe im Bereich von 64K Byte bis 256K Byte aufweist, wird als der aktive Speicher (oder alternativ als der dynamische Speicher) bezeichnet und wird verwendet, um Anwendungsprogramme auszuführen. Der verbleibende Abschnitt 284 des Speichers der Vorrichtung, als statischer Speicher bezeichnet, wird verwendet, um Dateien, Datenbanktabellen und inaktive Anwendungen zu speichern. Die Adressbereiche für die verschiedenen Speicherabschnitte 280, 282, 284 können von jenen abweichen, die in 3 gezeigt sind. Beispielsweise kann der Betriebssystemabschnitt 280 bei den höchsten Adressen gelegen sein, anstelle der niedrigsten Adressen im Speicher, wie es in 3 angezeigt ist. Der Code für ein Anwendungsprogramm während einer Ausführung der Anwendung verbleibt normalerweise im statischen Speicher 284 (als eine oder mehrere CodeRessourcen), während ein aktiver Speicher 282 verwendet wird, um Variablen und vorübergehende Datenstrukturen zu speichern, welche von der Anwendung verwendet werden.
Das PalmOS unterstützt zwei Typen von Datenbanken: Datnsatzdatenbanken und Ressourcendatenbanken. In einer Datnsatzdatenbank, wie etwa einer Datenbank, die verwendet wird, um Adressen für eine Adressbuchanwendung zu speichern, ist jeder Datenbankeintrag ein einzelner Datensatz. Anwendungen und Bibliotheken sind Beispiele von Datensatzdatenbanken. Jeder Datensatz und jede Ressource ist im PalmOS in ihrer Größe auf 64K Byte begrenzt. Andererseits kann eine im PalmOS zu speichernde "Datei" mehrere Datensätze und Ressourcen enthalten und ihre Größe kann 64K Byte übersteigen.
4 zeigt, dass die Hauptkomponenten einer Java Klassendatei 142 ein Header 292, ein Konstantenpool 294, ein Satz von Methoden 296 (welche die ausführbaren Prozeduren der Klasse bilden) und eine Ausnahmetabelle 298 (welche den Code anzeigt, der auszuführen ist, wenn bestimmte unerwartete Zustände auftreten) sind.
5 zeigt schematisch die Schritte des Prozesses 300 zum Erzeugen vorab geladener Klassendateien. Die vorab geladenen Klassendateien sind, sobald sie an einer Clientvorrichtung installiert wurden, für eine unmittelbare Ausführung durch die JVM in der Clientvorrichtung verfügbar, ohne dass sie einer Verifikation und einem Laden unterzogen werden. Durch Vorabladen eines Satzes von Klassendateien wird die Hochfahrzeit der JVM in der Clientvorrichtung deutlich reduziert und die Anforderungen der JVM an den aktiven Speicher (auch als dynamischen Speicher bezeichnet) werden deutlich reduziert, das die vorab geladenen Klassen nahzu in ihrer Gesamtheit in dem statischen Speicher der Clientvorrichtung gespeichert sind.
Als ein Vorabschritt, welcher nicht notwendigerweise durch das Autorensystem ausgeführt wird, wird ein Java-Quellcode 302 für die Methoden einer jeden Klasse durch einen Java-Kompilierer 304 in eine Klassendatei 142 kompiliert. Der "Kompilierer" 304 unterscheidet sich von einem herkömmlichen Kompilierer dahingehend, dass der sich ergebende Code kein Objektcode für einen bestimmten Prozessor ist, sondern stattdessen aus Java-Bytecodeprogrammen, Methoden genannt, besteht, die gemeinsam die Methoden einer Objektklasse bilden. Der Java-Kompilierer und die Java-Klassendateien sind bekannt und weitverbreitet in Gebrauch und brauchen daher an dieser Stelle nicht ausführlich diskutiert zu werden. Was jedoch erwähnt werden muss, ist, dass der Basissatz von Klassen, welche in die Java Virtual Machine geladen werden, ebenso lange vor der Entwicklung der vorliegenden Erfindung etabliert wurden, und dass daher der Satz von Klassendateien 142, welche vorab geladen werden sollen, auch gut von einer anderen Quelle als dem Autorensystem erhalten werden kann.
Die Offline-Klassenladeeinrichtung 150 nimmt einen Satz von Klassendateien 142 und erzeugt automatisch aus jenen ein C-Sprachprogramm 152, welches dann, wenn es ausgeführt wird, einen Satz von Dateien 158 (als Ressourcenmodule bezeichnet) zum Laden in die Clientvorrichtungen bildet. Natürlich könnte das Programm 152 in einer beliebigen Zahl anderer Sprachen, einschließlich Java, Pascal und C++, geschrieben sein und somit ist die bestimmte für das Programm 152 verwendete Rechnersprache nicht kritisch. Wichtiger ist, dass der Grund für eine Bildung der Dateien 158 unter Verwendung eines Programms 152, anstelle das Programm direkt zu erzeugen, darin liegt, dass die Dateien 158 Tausende von Zeigern enthalten, welche nicht nur schwierig durch Hand zu errechnen wären, sondern deren Werte sich jedesmal ändern würden, wenn eine Änderung entweder an den Klassendateien 142 oder an den Datenstrukturen in den Dateien 158 ausgeführt wird. Wenn beispielsweise eine neue Optimierung implementiert würde, um die durch die Datenstrukturen in den Dateien 158 repräsentierten Methoden effizienter zu machen, wenn sie durch die Clientvorrichtungen ausgeführt werden, müssten viele oder alle Zeiger erneut berechnet werden. Indem man die Zeiger zu Programmausdrücken macht, werden alle Zeigerwerte durch den Kompilierer 154, welcher zur Kompilierung des Programms 152 verwendet wird, automatisch aufgelöst.
Der Inhalt und die Struktur des Programms 152 werden indirekt erläutert, durch Erläuterung des Inhalts und der Struktur der durch das Programm 152 erzeugten Ressourcendateien 158. Jedoch besteht das Programm 152 in sehr großem Umfang aus einem Satz von Datenstrukturausdrücken, welche Information für jede der Klassendateien enthalten, die in dem Satz von vorab geladenen Klassen enthalten sein soll. Elemente in zahlreichen der Datenstrukturausdrücke umfassen Verweise auf Elemente in anderen Datenstrukturen. Es sind diese Verweise, welche durch den Kompilierer 154 in Zeiger aufgelöst werden.
Der Kompilierer kompiliert das Programm 152 in ein Programm, welches hier als JVM-Offline-Klassendatei bezeichnet wird. Eine Programmausführungseinrichtung führt die JVM-Offline-Klassendatei 156 aus, welche einen Satz von Dateien erzeugt, die hier als Ressourcenmodule 158 identifiziert sind. Die Ressourcenmodule 158 können in einer oder mehreren Dateien gespeichert sein, da die Anzahl an Dateien von keiner besonderen Wichtigkeit ist. Logischerweise umfassen die Ressourcenmodule jedoch einige unterschiedliche Module, von denen jedes gesondert diskutiert und in Wirklichkeit als eine gesonderte Ressource in den Clientvorrichtungen gespeichert werden wird.
Als Nächstes wird ein Kompilierer 160 für die Clientvorrichtung verwendet, um einige Sätze von Programmen 136, 136, 312 zu kompilieren, um die Programme und die Datenstrukturen zu erzeugen, welche in die Clientvorrichtungen geladen werden sollen. In einer Ausführungsform ist der Kompilierer 160 ein C-Sprachenkompilierer für die Clientvorrichtung, welcher einen Maschinenobjektcode erzeugt, der durch die Clientvorrichtungen ausführbar ist. Die zu kompilierenden Programme umfassen den Code 136 für die Java Virtual Machine, welcher einen Satz von Unterprogrammen umfasst, mit einer Programmverifizierungseinrichtung, einer Klassenladeeinrichtung, einem Programminterpretierer und zahlreichen anderen Unterprogrammen. Der Code 136 für die Java Virtual Machine umfasst weiterhin einen Satz von ca. fünfzig "Maschinenmethoden", welche Methoden zum Durchführen von Hardwarespezifischen Vorgängen sind, wie etwa Eingabe/Ausgabevorgänge, die durch die Clientvorrichtungen unter Verwendung von Maschinenobjektcode ausgeführt werden müssen.
Ein weiteres vom Kompilierer 160 kompiliertes Programm ist die JVM-Hochfahrprozedur 138, welches ein spezielles Programm ist, das den momentanen Ort der Ressourcenmodule zu der Zeit bestimmt, zu welcher die JVM ausgeführt werden soll, alle Zeiger in den Ressourcenmodulen auflöst und aktualisiert, sodass sie zu den korrekten Stellen im Speicher zeigen. Die physikalischen Speicherstellen, bei welchen die Ressourcenmodule gespeichert sind, können von einer Ausführung der JVM zur nächsten sich ändern und da die Clientvorrichtungen keine Verwaltungseinrichtung zur Verwaltung virtuellen Speichers aufweisen, wird die JVM-Hochfahrprozedur 138 verwendet, um alle Absolutadressenzeiger in den Ressourcenmodulen zu aktualisieren, um die momentanen Stellen der Ressourcenmodule zu berücksichtigen.
Eine noch weitere durch den Kompilierer 160 kompilierte Datenstruktur ist ein Programm 312, welches eine als Maschinenmethodentabelle bezeichnete Datenstruktur definiert. Das Maschinenmethodentabellenprogramm 312 wird durch die Offline-Klassenladeeinrichtung 150 erzeugt und besteht aus einer Datenstrutkur 320 (6) mit zwei Spalten, wobei eine Spalte Versatzwerte in eine Methodentabellendatenstruktur anzeigt, welche unten erläutert wird, und wobei die andere Spalte die Speicherstellen der entsprechenden Maschinenmethoden in dem Speicher der Clientvorrichtung anzeichnet. Der Kompilierer 160 löst die Stellen der Maschinenmethoden auf und speichert sie in der resultierenden Maschinenmethodentabelle 320 (6), welche als ein gesondert kompiliertes Programm behandelt wird. Genauer wird die Maschinenmethodentabelle 320 durch den Kompilierer 160 in einer "DatenRessource" 168 eingeschlossen, welche einem Satz von JVM-CodeRessourcen 132 zugeordnet ist; die DatenRessource 168 umfasst alle durch die kompilierte JVM und die Hochfahrprozedur verwendeten Variablen.
Die Ressourcenmodule 158 werden nicht durch den Kompilierer 160 kompiliert. Stattdessen werden sie in das vom Kompilierer 160 erzeugte Modul "eingeschlossen" ("included"), und zwar durch die Verwendung einer Direktive auf eine Verknüpfungseinrichtung ("Linker"), welcher ein Teil des Kompilierers 160 ist. Das durch den Kompilierer 160 erzeugte Modul umfasst ein Lademodul 162 für die Clientvorrichtung (welche im Grunde aus den Ressourcenmodulen 158 besteht), einen Satz von JVM-CodeRessourcen 163, welche gemeinsam den gesamten kompilierten Code 164 für die JVM und den kompilierten Code 166 für die JVM-Hochfahrprozedur enthalten, sowie eine zugeordnete JVM-DatenRessource 168, welche die kompilierte Maschinenmethodentabelle 320 umfasst. Das JVM-Programm wird in eine Mehrzahl von CodeRessourcen (von welchen jede eine Größe von weniger als 64K Byte aufweist) aufgebrochen, da die Gesamtgröße des JVM-Programms die Größengrenze von Ressourcen übersteigt.
Ressourcenmodule und Hauptdatenstrukturen
Mit Bezugnahme auf 7, 8, 9A – 9C und 10 – 15 wird als Nächstes der Inhalt und die Struktur der Ressourcenmodule 162, 158 diskutiert werden. Die primären Ressourcenmodule, von welchen jedes eine Größe von weniger als der Ressourcengrößengrenze (z.B. 64K Byte) der Clientvorrichtung aufweist, sind:

– eine Inhaltstabelle 350, welche verwendet wird, um die Clientspeicherstellen der anderen Module zu verfolgen;
– eine Internierte-Zeichenketten-Tabelle 352 zum Speichern von Java-Zeichenkettenobjekten;
– eine UTF-Zeichenkettentabelle 354 zum Speichern von Zeichenketten variabler Länge (UTF-Zeichenketten);
– eine Klassentabelle 356 zum Speichern von Information über die vorab geladenen Klassen;
– Methodentabellen 358 zum Speichern von Information über die Methoden der vorab geladenen Klassen;
– Feldtabellen 360 für eine Zeichenketteninformation über die Felder der vorab geladenen Klassen;
– ein Konstantenpool 362 zum Speichern konstanter numerischer Werte und Zeiger auf Felder, Methoden und internierten Zeichenketten, welche durch die Methoden der vorab geladenen Klassen verwendet werden;
– Behandlungsroutinentabellen 364 zum Speichern von Information über Ausnahmebehandlungsroutinen, welche den Methoden der vorab geladenen Klassen zugeordnet sind;
– Schnittstellentabellen 366 zum Speichern von Information über Schnittstellen, welche durch jede der vorab geladenen Java-Klassen implementiert sind;
– ein Codemodul 368 zum Speichern der Bytecodes der Methoden und Ausnahmebehandlungsroutinen der vorab geladenen Klassen; und
– eine Statische-Daten-Tabelle 370 zum Speichern der Werte von Variablen, welche auf einer Pro-Klassen-Basis alloziert sind, im Gegensatz zu Variablen, welche auf einer Pro-Objekt-Instanz-Basis alloziert sind.

Wie aus den weiteren Beschreibungen unten offensichtlich werden wird, weisen einige, jedoch nicht alle Ressourcenmodule, Zeiger auf Posten in anderen der Module auf. Beispielsweise weisen die CodeRessource 368, die BehandlungsroutinentabellenRessource 364 und die SchnittstellentabellenRessource 366 keinerlei Zeiger in sich auf. Die KlassentabellenRessource 356, MethodentabellenRessource 358 sind Beispiele von Ressourcen, welche Zeiger haben. Darüber hinaus weisen alle anderen Module als die InhaltstabellenRessource Posten auf, welche die Ziele von Zeigern in anderen der Module sind, und selbst die Inhaltstabelle kann derart aufgestellt sein, dass sie einen Zeiger auf sich selbst enthält.
Die Statische-Daten-Tabelle 370 ist tatsächlich ein Platzhalter, welcher nicht in die Clientvorrichtungen geladen zu werden braucht. Stattdessen wird die Statische-Daten-Tabelle während einer Ausführung der JVM erzeugt und in dem aktiven Speicher der Clientvorrichtung gespeichert. Jedoch ist die Statische-Daten-Tabelle in dem Lademodul enthalten, wenigstens während ihrer anfänglichen Erzeugung, da die anderen Module Zeiger in die unterschiedlichen Felder (d.h. Einträge) der Statischen-Daten-Tabelle 370 umfassen. Zeiger auf Posten in der Statischen-Daten-Tabelle erfordern eine Verschiebung oder Aktualisierung durch die Hochfahrprozedur und zwar in der gleichen Art und Weise wie die Zeiger auf andere Ressourcen. Da die Stelle der Statischen-Daten-Tabelle in dem aktiven Speicher der Clientvorrichtung sich von einer Ausführung zur nächsten verändern kann, müssen Zeiger zu Posten in der Statischen-Daten-Tabelle jedesmal aktualisiert werden, wenn die JVM-Hochfahrprozedur ausgeführt wird.
Die in 8 gezeigte Inhaltstabelle 350 wird verwendet, um die Speicherstelle und Größe eines jeden der Ressourcenmodule zu speichern. Anfänglich sind die Adressstellen ein beliebiger Satz von Werten, beispielsweise basiert auf ihren Stellen innerhalb einer Lademoduldatei. Jedesmal, wenn die JVM-Hochfahrprozedur durch eine Clientvorrichtung ausgeführt wird, werden die Adressen in der Inhaltstabelle aktualisiert, um die momentanen Stellen jener Ressourcen innerhalb des Speichers der Clientvorrichtung anzuzeigen. Diese Prozedur wird unten ausführlicher beschrieben werden. In einer bevorzugten Ausführungsform speichert die Inhaltstabelle 350 darüber hinaus einen Satz von "Hauptwerten" ("key values"), einschließlich Zeigern auf die Klassentabelle in der KlassentabellenRessource 356, den Klassenblock für die als java.lang.object bezeichnete Klasse (die Top-Level-Klasse), die in 9A, 9B und 10 gezeigten Hash-Tabellen und andere Hauptdatenstrukturen.
Die UTF-Zeichenkettentabelle 354, wie sie in 9A gezeigt ist, ist unter Verwendung einer Hash-Tabelle implementiert. Die Hash-Tabelle enthält eine Anzahl an Speicherbereichen ("Buckets"), in welche Zeichenketten durch eine entsprechende Hash-Funktion (welche in der JVM enthalten ist) gemappt werden. Die Hash-Tabelle umfasst einen Header, welcher einen Längenwert 380 umfasst, der die Anzahl an Speicherbereichen in der Tabelle anzeigt, einen Zählwert 382, welcher die Anzahl an UTF-Zeichenketten 386 in der Tabelle anzeigt, sowie einen Satz von Speicherbereichen ("buckets") 384. Jeder Speicherbereich 384 enthält einen Zeiger auf eine verknüpfte Liste von null oder mehr UTF-Zeichenketten 386. Der Zeiger in jedem Speicherbereich zeigt auf die erste UTF-Zeichenkette, wenn eine vorhanden ist, in der verknüpften Liste. Jede UTF-Zeichenkette 386 umfasst einen Zeiger 390 zu einer nächsten UTF-Zeichenkette, einem Längenfeld 392, welches die Länge gemessen als eine Anzahl von Bytes in der Zeichenkette angibt, und einem Bytefeld 394, welches die Zeichenkette selbst speichert.
Die Internierte-Zeichenketten-Tabelle 352 ist in ihrer Struktur der UTF-Zeichenkettentabelle 354 ähnlich. Insbesondere ist die Internierte- Zeichenketten-Tabelle 352, wie sie 9B gezeigt ist, unter Verwendung einer Hash-Tabelle implementiert. Die Hash-Tabelle enthält eine Anzahl von Speicherbereichen ("buckets"), in welche Zeichenkettenobjekte durch eine entsprechende Hash-Funktion (welche in der JVM enthalten ist) gemappt werden. Die Hash-Tabelle umfasst einen Header, welcher einen Längenwert 400 umfasst, der die Anzahl an Speicherbereichen in der Tabelle anzeigt, einen Zählwert 402 umfasst, welcher die Anzahl an Zeichenkettenobjekten 408 in der Tabelle anzeigt, und einen Satz von Speicherbereichen ("buckets") 404 umfasst. Jeder Speicherbereich 404 enthält einen Zeiger auf eine verknüpfte Liste von null oder mehr Zellen 406. Der Zeiger in jedem Speicherbereich zeigt auf die erste Zelle 406, wenn eine solche vorhanden ist, in der verknüpften Liste. Jede Zelle 406 um fasst einen Zeiger auf eine nächste Zelle und einen Zeiger auf ein Zeichenkettenobjekt 408 (oder genauer gesagt ein Objekt des Typs "java.lang.String"). Wie in 9 gezeigt ist, umfasst ein Zeichenkettenobjekt 408 typischerweise einen Zeiger 410 zur Klasse "java.lang.String", einen Zeiger auf eine Instanz eines Objekts des Typs
, sowie einen Offset 414 in ein Feld von Zeichen hinein, und einen Indikator 416 der Länge der Zeichenkette für das momentane Objekt. Das Feld von Zeichen 420 speichert alle Zeichenketten der Zeichenkettenobjekte, wobei die Stelle einer jeden solchen Zeichenkette in dem Feld durch den Offset und die Längenfelder 414, 416 der jeweiligen Zeichenkettenobjekte angezeigt wird. Um Raum zu sparen, wird lediglich eine
-Objektinstanz 418 gespeichert und alle Zeichenkettenobjekte zeigen auf diese gleiche einzige Instanz des
-Objekts 418.
Die Klassentabelle, wie sie in 10 gezeigt ist, ist eine weitere Hash-Tabelle mit einer Anzahl an Speicherbereichen ("buckets") 422, welche auf verknüpfte Listen von Klassenblöcken 424 zeigen. Die Tabelle umfasst ein Längenfeld 425, welches die Anzahl an Speicherbereichen in der Tabelle anzeigt, sowie ein Zählfeld 426, welches die Anzahl an Klassenblöcken in der Tabelle anzeigt.
Jeder Klassenblock 424, wie er in 11 gezeigt ist, umfasst:

– einen Zeiger 430 auf einen nächsten Klassenblock, wenn es einen solchen gibt;
– einen Zeiger 432 auf den Namen der dem Klassenblock zugeordneten Klasse; der Klassenname ist in einer UTF-Zeichenkette bei der in diesem Zeiger gespeicherten Adresse gespeichert;
– einen Zeiger 434 zu dem Klassenblock für die Überklasse der dem Klassenblock zugeordneten Klasse;
– einen Zeiger 436 auf eine Methodentabelle 450, welche wiederum auf die Methoden der dem Klassenblock zugeordneten Klasse zeigt;
– einen Zeiger 436 auf eine Feldtabelle 500, welche die Felder der dem Klassenblock zugeordneten Klasse definiert; sowie
– einen Zeiger 438 auf eine Konstantenpooltabelle 510 für die dem Klassenblock zugeordnete Klasse.

Die MethodentabellenRessource 358 speichert einen Satz von C-Methodentabellen 450 (siehe 7 und 12), wobei C die Anzahl an Klassendateien in dem Lademodul 162 ist. Jeder Klassenblock 462 zeigt auf eine der Methodentabellen 450. In ähnlicher Weise speichert die FeldtabellenRessource 360 einen Satz von C-Feldtabellen 500 (13), speichert die KonstantenpoolRessource 362 einen Satz von Konstantenpooltabellen 520 (14), speichert die BehandlungsroutinentabellenRessource 364 einen Satz von Ausnahmetabellen 454 (12) und speichert die CodeRessource 368 einen Satz von Codeblocks 452 (12).
Jede Methodentabelle 450 enthält einen Satz von Methodenblöcken 460, einen für jede Methode der zugeordneten Klasse. Die Tabelle umfasst ein Zählfeld 462, welches die Anzahl an Methodenblöcken in der Tabelle anzeigt, sowie ein Längenfeld 464, welches die Größe der Tabelle anzeigt. Jeder Methodenblock umfasst einen Zeiger 466 auf einen Codeblock 452 und einen weiteren Zeiger 468 auf eine Ausnahmetabelle 454, und ebenso andere Information, die für die vorliegende Diskussion nicht relevant ist.
Jeder Codeblock 452 enthält ein ausführbares Programm (auch als Code oder ausführbare Anweisungen bezeichnet), welches in der bevorzugten Ausführungsform ein Java-Sprachen-Bytecodeprogramm (d.h. eine Methode) ist.
Jede Ausnahmetabelle 454 enthält einen Ausnahmebehandlungsroutineneintrag 480 für jede Ausnahmebehandlungsroutine, die durch eine entsprechende Methode spezifiziert ist. Ein Zählfeld 482 zeigt die Anzahl an Ausnahmebehandlungsroutineneinträgen an und jeder Eintrag 480 zeigt einen Codebereich in der Methode (d.h. den ersten und den letzen Bytecode) an, auf welchen eine bestimmte Behandlungsroutine anwendbar ist, einen Offset-Wert, welcher die Stelle der Ausnahmebehandlungsroutine in dem Codeblock für die Methode anzeigt und die Art von Ausnahme(n), für welche die Ausnahmebehandlungs routine verwendet werden soll.
Wie in 13 gezeigt ist, enthält jede Feldtabelle 500 der FeldtabellenRessource einen Satz von Feldeinträgen 502. Jeder Feldeintrag 502 umfasst einen Offset oder Zeigeer, den Datentyp des Feldes sowie einen Zeiger auf eine UTF-Zeichenkette, welche den Namen des Feldes enthält. Wenn das dem Feldeintrag entsprechende Feld ein "Pro-Objektinstanz"-Feld ist, welches in jedem Objekt der zugeordneten Klasse (Objekttyp) enthalten ist, enthält der Feldeintrag einen Offset und dieser Offset bezeichnet die Position des entsprechenden Feldes in jedem Objekt der zugeordneten Klasse. Wenn andererseits das dem Feldeintrag entsprechende Feld eine "Einmal-Pro-Klasse"-Variable ist, welche in dem Statische-Daten-Feld gespeichert ist, enthält der Feldeintrag einen Zeiger auf einen Eintrag in dem Statische-Daten-Feld anstelle eines Offset-Werts. Die Feldtabelle 500 umfasst weiterhin ein Längenfeld 504, welches die Anzahl an Feldeinträgen 502 in der Tabelle bezeichnet.
Wie in 14 gezeigt ist, weist der Konstantenpool 520 für eine bestimmte Klasse ein Größenfeld 522 auf, welches die Anzahl an Posten in dem Pool anzeigt. Jeder Posten in dem Pool wird repräsentiert durch ein 1-Byte-Tag und einen 4-Byte-Posten ("item"). Die Tags 524 sind in einem Feld gespeichert und die Posten in einem anderen, um Anforderungen an Adressierungsgrenzen zu erfüllen. Jeder Tag 524 bezeichnet den Datentyp einer Konstante, während der entsprechende Posten 526 entweder ein Zeiger auf einen Feldeintrag 502 in einer Feldtabelle 500 ist, ein Zeiger auf eine Methode (d.h. auf einen Methodenblock 460 in einer Methodentabelle 450) ist, ein Zeiger auf eine UTF-Zeichenkette in der UTF-Zeichenkettentabelle 354 ist oder ein numerischer Wert ist (z.B. eine ganze Zahl oder ein Fließkommawert). Der durch den Tag 524 spezifizierte Datentyp spezifiziert, ob der Posten 526 einen numerischen Wert oder einen Zeiger enthält, ebenso wie den Typ des Zeigers.
Prozess zum Initialisieren und Starten einer Java Virtual Machine in der Clientvorrichtung
Mit Verweis auf 15 umfasst jedes der Ressourcenmodule zwei Bytes von Leerinformation an seinem Ende. Der Grund dafür lautet wie folgt. Die Speicherstelle eines jeden Moduls kann sich ändern, wenn die JVM nicht ausgeführt wird. Das bedeutet, die Clientvorrichtung kann unter Umständen aus verschiedenen Gründen Ressourcen innerhalb ihres Speichers verschieben. Das Problem darin ist, dass die Clientvorrichtung eine Ressource an einer Stelle speichern kann, welche keine 0 mod 4-Adresse ist (d.h. eine Adresse, die ohne Rest durch vier teilbar ist). Genauer kann die Startadresse einer Ressource eine 2 mod 4-Adresse sein. Jedoch verlässt sich die JVM darauf, dass bestimmte Datenstrukturen bei Stellen gespeichert sind, welche 0 mod 4 sind. Dieses Problem wird gelöst durch (A) Speichern von zwei Bytes von Leerinformation an entweder dem Ende oder dem Beginn eines jeden Ressourcenmoduls, und (B) beim Hochfahren der JVM, durch Festhalten der Stelle der JVM-Ressourcenmodule, und (C) durch Rotieren dieser zwei Bytes zum Beginn oder zum Ende eines jeden Ressourcenmoduls, wann immer es notwendig ist, damit das erste Byte der Nicht-Leerinformation in dem Ressourcenmodul an einer 0 mod 4-Adresse angeordnet ist. Es ist anzumerken, dass dann, wenn ein Ressourcenmodul zuvor bei einer 2 mod 4-Adresse gespeichert war (und somit seine Leerbytes nach vorne bewegt worden waren) und dann als Nächstes bei einer 0 mod 4-Adresse gespeichert wird, die Leerbytes von der Vorderseite zu der Rückseite des Ressourcenmoduls bewegt werden müssen.
Wann immer die Leerbytes in einem Ressourcenmodul von hinten nach vorne bewegt werden, wird der entsprechende in der Inhaltstabelle 350 gespeicherte Stellenwert um zwei verringert, und wann immer die Leerbytes in einem Ressourcenmodul von vorne nach hinten bewegt werden, wird der in der Inhaltstabelle 350 gespeicherte entsprechende Stellenwert um zwei erhöht. Diese Einstellungen an der Inhaltstabelle ermöglichen, dass die nachfolgende Modifikation von Zeigern in den Ressourcenmodulen korrekt ausgeführt wird.
Bezug nehmend auf 16A und 16B müssen vor der Ausführung der JVM-Hochfahrprozedur die JVM, die Hochfahrprozedur und die Ressourcenmodule an der Clientvorrichtung (540) installiert werden, was bedeutet, dass sie in den Speicher der Vorrichtung gespeichert werden.
Wann immer die JVM durch eine Clientvorrichtung ausgeführt werden soll, geht ihrer Ausführung eine Ausführung der JVM-Hochfahrprozedur (542) voraus. Bei Abschluss der Hochfahrprozedur wird die JVM ausgeführt (544) und bei Abschluss der Ausführung der JVM werden alle JVM-Ressourcen, welche durch die Hochfahrprozedur festgehalten sind, freigegeben (546).
Die Hochfahrprozedur ist tatsächlich Teil derselben CodeRessource wie die JVM, hier als die JVM-CodeRessource bezeichnet, und darüber hinaus umfasst die JVM eine "DatenRessource", hier als JVM-DatenRessource bezeichnet. Die JVM-DatenRessource repräsentiert alle Variablen in der JVM, einschließlich der Maschinenmethodentabelle. Wenn die JVM-Hochfahrprozedur ausgeführt werden soll, kopiert das PalmOS automatisch die JVM-DatenRessource in einen aktiven Speicher (550). Dies bedeutet, dass das PalmOS für ein beliebiges durch die Palm-Vorrichtung auszuführendes Programm automatisch die entsprechende DatenRessource in einen aktiven Speicher kopiert.
Während die DatenRessource zum aktiven Speicher bewegt wird, aktualisiert das PalmOS darüber hinaus automatisch Zeiger innerhalb der DatenRessource derart, dass sie auf die korrekten Stellen innerhalb der zugeordneten CodeRessource(n) zeigen. Als Folge wird die Kopie der Maschinenmethodentabelle im aktiven Speicher automatisch durch das PalmOS aktualisiert, sodass es aktualisierte Zeiger auf die Maschinencodemethoden innerhalb der JVM-CodeRessourcen enthält.
Die Hochfahrprozedur erzeugt eine Arbeitskopie der Inhaltstabelle (551). Wie in 8 angezeigt ist, umfasst die Arbeitskopie der Inhaltstabelle eine "ΔLocation"-Spalte zum Speichern der Differenz zwischen der früheren und der momentanen Stelle (Location) eines jeden der Ressourcenmodule.
Darüber hinaus hält sie jede der von der JVM verwendeten Ressourcen fest, sodass ihre Stelle im Speicher nicht geändert werden kann, bis die Ressourcen freigegeben werden, nachdem eine Ausführung der JVM abgeschlossen ist. Die Prozedur stellt dann die Stellen der zwei Bytes Leerinformation in jedem JVM-Ressourcenmodul ein, jedoch nur dann, wenn dies notwendig ist, um die erste Nicht-Leerdatenstruktur in jeder derartigen Ressource bei einer 0 mod 4-Adresse zu positionieren, und stellt die Startadresse der Module ein, wie sie dementsprechend in der Inhaltstabelle aufgezeichnet sind (551).
Ein Feld (als das Statische-Daten-Feld oder die Statische-Daten-Tabelle bezeichnet) von modifizierbaren Pro-Klassen-Variablen, welche den vorab geladenen Klassen zugeordnet sind, wird in dem aktiven Speicher eingerichtet (552). Die Stelle dieses Feldes wird notiert und während eines Zeigereinstellschrittes 556 verwendet.
Als Nächstes bestimmt die Hochfahrprozedur die momentanen Startstellen der JVM-Ressourcen, vergleicht die mit den vorherigen Startstellen, wie sie in der Inhaltstabelle angezeigt sind, und erzeugt einen ΔLocation-Wert, welcher gleich der Differenz zwischen der momentanen und der früheren Stelle ist, und zwar für jedes der JVM-Ressourcenmodule (554). Wenn alle ΔLocation-Werte null betragen, was anzeigt, dass keines der JVM-Ressourcenmodule seit der letzten Ausführung der JVM bewegt wurde, dann wird der Großteil der in Schritt 556 (Einstellen von Zeigern) ausgeführten Arbeit übersprungen. Es wird angemerkt, dass das Statische-Daten-Feld eine der "Ressourcen" ist, für welche eine Zeile in der Inhaltstabelle vorhanden ist, selbst wenn diese Ressource bei jeder Ausführung der JVM erneut erzeugt wird. Die Änderung der Stelle des Statische-Daten-Feldes von einer Ausführung zur nächsten wird verwendet, um Zeiger in den FeldtabellenRessourcen auf Einträge in dem Statische-Daten-Feld zu aktualisieren (in Schritt 556).
Der Schritt (556) einer Einstellung der Zeiger innerhalb der JVM-Ressourcen auf Grundlage der Änderungen der Startstellen der JVM-Ressourcen ist derjenige Schritt, welcher ermöglicht, dass die JVM in einer Vorrichtung ausgeführt wird, welche keine Verwaltungseinrichtung zur Verwaltung eines virtuellen Speichers aufweist. Die Einstellung der Zeiger wird wie folgt erreicht. Für die UTF-Zeichenkettentabelle 354 und die Internierte-Zeichenketten-Tabelle 352 werden die Werte der Zeiger in diesen Tabellen durch einen Betrag eingestellt, welcher gleich der Änderung der Stelle für jede dieser Tabellen ist. Dann, wenn sich beispielsweise die UTF-Zeichenkettentabelle 354 um +1024 Byte bewegt hat, werden alle Zeiger in dieser Tabelle um 1024 erhöht. In der Internierte-Zeichenketten-Tabelle 352 werden die Zeiger 410 auf die java.lang.String-Klasse um den gleichen Betrag eingestellt wie die ΔLocation für die KlassentabellenRessource.
Innerhalb der Klassentabelle 356, Methodentabellen 450, Feldtabellen 500 und Konstantenpools 520 wird jeder Zeiger (A) überprüft, um sicherzustellen, dass er auf eine Stelle innerhalb der richtigen Ressource zeigt und (B) durch die ΔLocation für diese Ressource eingestellt. Der Satz von einzustellenden Zeigern wird durch Verfolgung durch alle Klassenblöcke der Klassentabelle hindurch und durch Verfolgung der Zeiger darin aufgefunden, um alle Methodentabellen, Feldtabellen und Konstantenpools in den JVM-Ressourcen zu lokalisieren, und dann durch Einstellen ihrer jeweiligen Zeiger.
Lediglich die FeldtabellenRessource enthält Zeiger auf Posten in dem Statische-Daten-Feld. Diese Zeiger werden nach Maßgabe der Änderung der Stelle (wenn eine solche vorhanden ist) des Statische-Daten-Feldes von der vorherigen Ausführung der JVM zu der momentanen Ausführung der JVM aktualisiert. In einer bevorzugten Ausführungsform prüft die JVM-Hochfahrprozedur (Schritt 554) den ΔLocation-Wert für alle anderen Ressourcen als das Statische-Daten-Feld und schaltet zu einem "schnellen" Aktualisierungsprozess, wenn alle diese ΔLocation-Werte gleich null sind. In dem schnellen Aktualisierungsprozess werden lediglich die Zeiger in der FeldtabellenRessource in Schritt 556 aktualisiert, welche auf das Statische-Daten-Feld zeigen.
Zeiger in den Methodentabellen auf Maschinenmethoden werden gesondert ak tualisiert, und zwar in Schritt 558, unter Verwendung von Werten, die in der Maschinenmethodentabelle gespeichert sind. Wie oben beschrieben wurde, werden die Zeiger in der Maschinenmethodentabelle bei Schritt 550 derart aktualisiert, dass sie auf die momentanen Stellen der Maschinenmethoden in den Java-CodeRessourcen zeigen. Die Maschinenmethodentabelle enthält eine Zeile für jede Maschinenmethode, wobei sie einen Offset in die MethodentabellenRessource und einen Zeiger auf die Maschinenmethode enthält. In Schritt 558 wird für jede Zeile der Maschinenmethodentabelle 320 der Zeiger in der Zeile an die Stelle in der MethodentabellenRessource kopiert, welche durch den Offset-Wert in jener Zeile angezeigt ist. Schritt 558 wird selbst dann ausgeführt, wenn die ΔLocation-Werte für alle diese in der Inhaltstabelle verzeichneten Ressourcen gleich null sind.
Es wird an dieser Stelle angemerkt, dass in einer bevorzugten Ausführungsform, in welcher die Clientvorrichtung eine Palm-Vorrichtung ist, während die JVM-Ressourcen in dem "statischen Speicher" der Clientvorrichtung gespeichert werden, die Inhalte jener Ressourcen durch die Verwendung von geeigneten Betriebssystembefehlen überschrieben werden können. Während ein Schreiben von neuen Werten in den statischen Speicher die Verwendung spezieller Betriebssystembefehle erfordert und mehr Zeit benötigt als normale Schreibvorgänge zum aktiven Speicher 282 (3) der Clientvorrichtung, wird der Zeigereinstellprozess lediglich einmal für jede Ausführung der JVM-Hochfahrprozedur ausgeführt.
In einer bevorzugten Ausführungsform werden die Zeigeraktualisierungen in Arbeitskopien der JVM-Ressourcen ausgeführt. Wann immer es möglich ist, werden diese Arbeitskopien im aktiven Speicher gespeichert. Jedoch zwingen typischerweise Einschränkungen in der Menge an aktivem Speicher dazu, dass wenigstens einige der Arbeitskopien im statischen Speicher gespeichert werden. Arbeitskopien werden nicht aus den JVM-Ressourcen gemacht, die keine Zeiger in sich aufweisen. In Schritt 560 wird die Inhaltstabelle durch Addieren der ΔLocation für jede Ressource zu ihrer Startadresse finalisiert.
Dann wird für jede JVM-Ressource, für welche eine Arbeitskopie vorhanden ist, die JVM-Ressource durch ihre Arbeitskopie ersetzt. Der Grund dafür, dass die Inhaltstabelle und andere JVM-Ressourcen bis ganz am Ende der Hochfahrprozedur nicht geändert werden, liegt darin, dass dann, wenn die Hochfahrprozedur mitten im Prozess unterbrochen werden sollte, die Inhalte der Inhaltstabelle und der JVM-Ressourcen intern inkonsistent wären und es dann unmöglich wäre, alle Zeiger in den JVM-Ressourcen derart korrekt einzustellen, dass eine Wiederherstellung aus der Unterbrechung der Hochfahrprozedur erfolgt. Mit anderen Worten minimiert ein unverändertes Belassen der Inhaltstabelle und anderer JVM-Ressourcen bis zum Ende den Zeitbetrag, während welchem die Inhalte der JVM-Ressourcen intern inkonsistent sind. Dies macht es sehr viel wahrscheinlicher, dass die Hochfahrprozedur in der Lage sein wird, von einem Zusammenbruch oder einer anderen Unterbrechung des Hochfahrprozesses aus eine Wiederherstellung zu erreichen.
Nachdem der Hochfahrprozess abgeschlossen ist, wird die JVM ausgeführt (544, 16A). Die JVM kann dann ein einzelnes Applet ausführen oder kann Java-Programme ausführen, bevor ihre eigene Ausführung angehalten wird. Wenn die Ausführung der JVM abgeschlossen ist, werden die JVM-Ressourcen freigegeben, wodurch das Betriebssystem in die Lage versetzt wird, sie zu neuen Stellen im Speicher nach Maßgabe seiner internen Haushaltsrichtlinien zu verschieben.
Alternative Ausführungsformen
Die vorliegende Erfindung kann als ein Rechnerprogrammprodukt implementiert sein, welches einen Rechnerprogrammmechanismus umfasst, der in einem rechnerlesbaren Speichermedium eingebettet ist. Beispielsweise könnte das Rechnerprogrammprodukt die in 1 und 2 gezeigten Programmmodule enthalten. Diese Programmmodule können auf einer CD-ROM; einem Magnetplattenspeicherprodukt oder einem beliebigen anderen rechnerlesbaren Daten- oder -Programmspeicherprodukt gespeichert sein. Die Softwaremodule in dem Rechnerprogrammprodukt können auch elektronisch verteilt sein, über das Internet oder in anderer Art und Weise, und zwar durch Übertragung eines Computerdatensignals (in welchem die Softwaremodule eingebettet sind) auf einer Trägerwelle.
Während die vorliegende Erfindung mit Bezugnahme auf wenige besondere Ausführungsformen beschrieben wurde, ist die Beschreibung für die Erfindung beispielgebend und ist nicht als die Erfindung beschränkend gedacht. Zahlreiche Modifikationen können Fachleuten einfallen, ohne von dem Rahmen der Erfindung abzuweichen, wie sie durch die angehängten Ansprüche definiert ist.

Claims

Verfahren zum Vorbereiten eines spezifizierten Satzes von Klassen, um diesen vorab in Client-Vorrichtungen (102) ohne Verwaltungseinrichtung zum Verwalten von virtuellem Speicher zu laden, das Verfahren umfassend: Umwandeln des spezifizierten Satzes von Klassen in eine Mehrzahl von Resourcenmodulen (158), wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; Bereitstellen eines kompilierten Interpretierers (164) zur Ausführung durch die Client-Vorrichtungen; wobei der Interpretierer zum Ausführen von Programmen in einer vordefinierten Rechnersprache dient und wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache umfasst; Bereitstellen einer kompilierten Hochfahrprozedur (166), welche durch die Client-Vorrichtungen dann ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird; wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe aktueller Speicherplätze der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtungen dient; sowie Erzeugen eines Lademoduls (162) zum Laden in die Client-Vorrichtungen, wobei das Lademodul eine Mehrzahl von Resourcenmodulen, den kompilierten Interpretierer und die kompilierte Hochfahrprozedur umfasst.
Verfahren nach Anspruch 1, bei welchem die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen-Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfassen, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten-Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Verfahren nach Anspruch 1, bei welchem die Hochfahrprozedur (166) Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Resourcenmodulen in dem Untersatz bei einer 0 mod 4 Adresse mit irgendeiner bestimmten der Client-Vorrichtungen umfasst.
Verfahren nach Anspruch 1, bei welchem die Resourcenmodule (158) eine Inhaltstabelle (350) enthalten, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Verfahren nach Anspruch 1, bei welchem die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Rechnerprogrammprodukt zur Verwendung in Verbindung mit einem Rechnersystem, wobei das Rechnerprogrammprodukt ein rechnerlesbares Speichermedium und darin eingebetteten Rechnerprogrammcode umfasst, welcher dann, wenn er auf dem Rechnersystem ausgeführt wird, einen spezifizierten Satz von Klassen vorbereitet, um sie vorab in Client-Vorrichtungen ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher zu laden, wobei der Rechnerprogrammcode umfasst: eine Klassen-Vorabladevorrichtung (150) zum Umwandeln eines spezifizierten Satzes von Klassen in eine Mehrzahl von Resourcenmodulen, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; einen Kompilierer (154) zum Kompilieren eines Interpretierers, zur Ausführung durch die Client-Vorrichtungen (102), um einen kompilierten Interpretierer zu erzeugen; wobei der Interpretierer zum Ausführen von Programmen in einer vordefinierten Rechnersprache dient und wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache umfasst; wobei der Kompilierer ferner zum Kompilieren einer Hochfahrprozedur (166) dient, welche durch die Client-Vorrichtungen ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird, um eine kompilierte Hochfahrprozedur zu erzeugen, wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von aktuellen Speicherstellen der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtungen dient; und wobei der Kompilierer ferner zum Erzeugen eines Lademoduls (162) zum Laden in die Client-Vorrichtungen dient, wobei das Lademodul die Mehrzahl von Resourcenmodulen, den kompilierten Interpretierer und die kompilierte Hochfahrprozedur umfasst.
Rechnerprogrammprodukt nach Anspruch 6, wobei die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen-Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfasst, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten-Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Rechnerprogrammprodukt nach Anspruch 6, bei welchem die Hochfahrprozedur (166) Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Resourcenmodule bei einer 0 mod 4 Adresse mit irgendeiner bestimmten der Client-Vorrichtungen umfasst.
Rechnerprogrammprodukt nach Anspruch 6, bei welchem die Resourcenmodule (158) eine Inhaltstabelle (350) enthalten, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Rechnerprogrammprodukt nach Anspruch 6, bei welchem die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Rechnersystem zum Vorbereiten eines spezifizierten Satzes von Klassen, um sie vorab in Client-Vorrichtungen ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher zu laden, das Rechnersystem umfassend: eine Datenverarbeitungseinheit (120); Speicher (124), um einen spezifizierten Satz von Klassen (140), einen Interpretierer (164) und eine Hochfahrprozedur (166) zu speichern, eine Klassen-Vorabladevorrichtung (150), welche durch die Datenverarbeitungseinheit ausführbar ist, zum Umwandeln eines spezifizierten Satzes von Klassen in eine Mehrzahl von Resourcenmodulen, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; einen Kompilierer (154), welcher durch die Datenverarbeitungseinheit ausführbar ist, zum Kompilieren eines Interpretierers, zur Ausführung durch die Client-Vorrichtungen ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher, um einen kompilierten Interpretierer zu erzeugen; wobei der Interpretierer zum Ausführen von Programmen in einer vordefinierten Rechnersprache dient und wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache umfasst; wobei der Kompilierer ferner zum Kompilieren einer Hochfahrprozedur (161) dient, welche durch die Client-Vorrichtungen ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird, um eine kompilierte Hochfahrprozedur zu erzeugen, wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von aktuellen Speicherstellen der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtungen dient; und wobei der Kompilierer ferner zum Erzeugen eines Lademoduls (162) zum Laden in die Client-Vorrichtungen dient, wobei das Lademodul die Mehrzahl von Resourcenmodulen, den kompilierten Interpretierer und die kompilierte Hochfahrprozedur umfasst.
Rechnersystem nach Anspruch 11, bei welchem die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen-Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfassen, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten-Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Rechnersystem nach Anspruch 11, bei welchem die Hochfahrprozedur (166) Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Resourcenmodule bei einer 0 mod 4 Adresse mit irgendeiner bestimmten der Client-Vorrichtungen umfasst.
Rechnersystem nach Anspruch 11, bei welchem die Resourcenmodule (158) eine Inhaltstabelle (350) enthalten, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Rechnersystem nach Anspruch 11, bei welchem die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Verfahren zum Betreiben einer Client-Vorrichtung ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher, umfassend: Speichern einer Mehrzahl von Resourcenmodulen (158) in einem Speicher (224) in der Client-Vorrichtung (102), wobei die Mehrzahl der Resourcenmodule einen Satz von Klassen repräsentiert, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; Ausführen von Programmen in einer vorbestimmten Rechnersprache unter Verwendung eines Interpretierers (164), wobei die ausgeführten Programme Methoden in dem Satz von Klassen enthalten; Ausführen einer Hochfahrprozedur (166) beim Laden des Interpretierers und vor Ausführen von Programmen unter Verwendung des Interpretierers, um Zeiger in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von tatsächlichen Speicherstellen der Resourcenmodule in der Client-Vorrichtung zu ersetzen.
Verfahren nach Anspruch 16, bei welchen die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen- Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfassen, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten-Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Verfahren nach Anspruch 16, bei welchem ein Ausführen einer Hochfahrprozedur (166) ein Positionieren einer ersten Datenstruktur in jedem aus wenigstens zwei der Resourcenmodule bei einer 0 mod 4 Adresse umfasst.
Verfahren nach Anspruch 16, bei welchem die Resourcenmodule (158) eine Inhaltstabelle (350) enthalten, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Verfahren nach Anspruch 16, bei welchem die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Rechnerprogrammprodukt zur Verwendung in Verbindung mit einem Rechnersystem, wobei das Rechnerprogrammprodukt ein rechnerlesbares Speichermedium und darin eingebetteten Rechnerprogrammcode umfasst, wobei der Rechnerprogrammcode umfasst: ein Lademodul (162) zum Laden in Client-Vorrichtungen (102) ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher, wobei das Lademodul umfasst: eine Mehrzahl von Resourcenmodulen (158), wobei die Mehrzahl der Resourcenmodule einen Satz von Klassen repräsentiert, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; einen Interpretierer (164) zum Ausführen von Programmen in einer vordefinierten Rechnersprache; wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache enthält; eine Hochfahrprozedur (166), welche durch die Client-Vorrichtungen dann ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird, wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von aktuellen Speicherstellen der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtungen dient.
Rechnerprogrammprodukt nach Anspruch 21, bei welchem die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen-Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfassen, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten- Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Rechnerprogrammprodukt nach Anspruch 21, bei welchem die Hochfahrprozedur (166) Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Resourcenmodule bei einer 0 mod 4 Adresse mit irgendeiner bestimmten der Client-Vorrichtungen umfasst.
Rechnerprogrammprodukt nach Anspruch 21, bei welchem die Resourcenmodule (158) eine Inhaltstabelle (350) enthält, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Rechnerprogrammprodukt nach Anspruch 21, bei welchem die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Client-Vorrichtung (102), umfassend: eine Speicherverarbeitungseinheit (220), einen Speicher (224) zum Speichern eines Betriebssystems (230) ohne Verwaltungseinrichtung zum Verwalten von virtuellem Speicher; einer Mehrzahl von Resourcenmodulen (158), wobei die Mehrzahl der Resourcenmodule einen Satz von Klassen repräsentiert, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; einen Interpretierer (164), welcher durch die Datenverarbeitungseinheit ausführbar ist, zum Ausführen von Programmen in einer vordefinierten Rechnersprache; wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache enthält; eine Hochfahrprozedur (166), welche durch die Datenverarbeitungseinheit ausführbar ist und welche durch die Client-Vorrichtungen dann ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird, wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von tatsächlichen Speicherstellen der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtung dient.
Client-Vorrichtung nach Anspruch 26, bei welcher die Resourcenmodule (158) ein Klassentabellen-Resourcenmodul (356), ein Methodentabellen-Resourcenmodul (358), ein Feldtabellen-Resourcenmodul (360), ein Konstantenpool-Resourcenmodul (362) und ein Zeichenketten-Resourcenmodul (354) umfassen, wobei die Klassendatenstruktur Zeiger zu Posten in den Methodentabellen-, Feldtabellen- und Konstantenpool-Resourcenmodulen enthält, wobei das Feldtabellen-Resourcenmodul Zeiger zu Posten in dem Zeichenketten-Resourcenmodul enthält, und wobei das Konstantenpool-Resourcenmodul Zeiger zu Posten in dem Feldtabellen-Resourcenmodul und zu Posten in dem Zeichenketten-Resourcenmodul enthält.
Client-Vorrichtung nach Anspruch 26, bei welcher die Hochfahrprozedur (166) Anweisungen zum Positionieren einer ersten Datenstruktur in jedem von wenigstens zwei der Resourcenmodule bei einer 0 mod 4 Adresse mit irgendeiner bestimmten der Client-Vorrichtungen umfasst.
Client-Vorrichtung nach Anspruch 26, bei welcher die Resourcenmodule (158) eine Inhaltstabelle (350) enthalten, welche eine Speicheradresse für jedes aus einem zweiten Untersatz der Resourcenmodule bezeichnet, wobei der zweite Untersatz jene der Resourcenmodule enthält, auf welche von wenigstens einem der Zeiger in den Resourcenmodulen gezeigt wird; die Hochfahrprozedur (166) Anweisungen enthält, um (A) eine momentane Speicheradresse für jedes der Resourcenmodule in dem zweiten Untersatz zu bestimmen, einen Differenzenwert für jedes Resourcenmodul im zweiten Untersatz zu bestimmen, welcher einer Differenz zwischen der momentanen Speicheradresse und der in der Inhaltstabelle angezeigten Speicheradresse entspricht, und um (B) wenigstens einen Untersatz der Zeiger in den Resourcenmodulen nach Maßgabe der Differenzenwerte einzustellen.
Client-Vorrichtung nach Anspruch 26, bei welcher die Resourcenmodule (158) ein Methodentabellenmodul (320) enthalten mit Zeigern zu einem Code für Methoden des spezifizierten Satzes von Klassen, wobei ein Untersatz der Zeiger in der Methodentabelle auf Maschinenmethoden in dem kompilierten Interpretierer zeigt.
Client-Vorrichtung nach Anspruch 26, bei welcher die Client-Vorrichtung (102) eine Anzeige umfasst; und der Speicher (224) ferner speichert: eine Browseranwendung (252), welche durch die Client-Vorrichtung ausführbar ist, zum Laden von Dokumenten von entfernt gelegenen Rechnern, einschließlich von Dokumenten, welche in sich eingebettet einen Verweis auf ein durch den Interpretierer ausführbares Applet aufweisen, sowie zum Anzeigen des Dokuments und von durch Ausführung des Applets erzeugten Bildern an der Anzeige.
Rechnerdatensignal, welches in einer Trägerwelle verkörpert ist und in sich einen Rechnerprogrammcode eingebettet aufweist, wobei der Rechnerprogrammcode umfasst: ein Lademodul (162) zum Laden in Client-Vorrichtungen (102) ohne Verwaltungseinrichtung zur Verwaltung von virtuellem Speicher, wobei das Lademodul umfasst: eine Mehrzahl von Resourcenmodulen (158), wobei die Mehrzahl der Resourcenmodule einen Satz von Klassen repräsentiert, wobei ein Untersatz der Resourcenmodule jeweils Posten enthält, welche Zeiger zu Posten in anderen der Resourcenmodule aufweisen; wobei jeder Zeiger eine Speicheradresse des Postens spezifiziert, auf welchen gezeigt wird; einen Interpretierer (164) zum Ausführen von Programmen in einer vordefinierten Rechnersprache; wobei der spezifizierte Satz von Klassen Methoden in der vordefinierten Rechnersprache enthält; eine Hochfahrprozedur (166), welche durch die Client-Vorrichtungen dann ausgeführt werden soll, wenn der Interpretierer zur Ausführung geladen wird, wobei die Hochfahrprozedur zum Ersetzen von Zeigern in den Resourcenmodulen durch aktualisierte Zeiger nach Maßgabe von tatsächlichen Speicherstellen der Resourcenmodule in irgendeiner bestimmten der Client-Vorrichtungen dient.