DE69724516T2

DE69724516T2 - Rechnersystem und Verfahren zur Ausführung von architekturspezifischem Programmcode mit geringen Laufzeitspeicherbereichsanforderungen

Info

Publication number: DE69724516T2
Application number: DE69724516T
Authority: DE
Inventors: Timothy G. Palo Alto Lindholm
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-06-05
Filing date: 1997-06-04
Publication date: 2004-04-22
Anticipated expiration: 2017-06-05
Also published as: CN1122228C; US5794049A; KR980004025A; SG74591A1; TW332881B; EP0811910A3; KR100528844B1; EP0811910A2; JPH10228379A; JP3955358B2; DE69724516D1; EP0811910B1; CN1174359A

Description

Die vorliegende Erfindung bezieht sich auf Computersysteme und Verfahren zum Ausführen von Programmen mit reduzierten Laufzeitspeicherplatz-Anforderungen. Insbesondere ist die vorliegende Erfindung auf Computersysteme und Verfahren in einem Netzwerk zum Ausführen von architekturspezifischem Code abgestellt, welcher von architekturneutralem Code entwickelt wird, der über das Netzwerk übertragen wird, so dass die Laufzeitspeicherplatz-Anforderungen des architekturspezifischen Codes reduziert werden.
HINTERGRUND DER ERFINDUNG
Computersysteme werden zurzeit dazu gebaut oder konfiguriert, um Eigenschaften von Programmen auszunutzen, deren Code in architekturneutralem (AN) Binärformat, im Folgenden als AN-Code bezeichnet, vorliegt. Der AN-Code dieser Programme ist daher unabhängig von der spezifischen Architektur oder Plattform des Computersystems.
Die Bezeichnung Architektur ist für den Zweck dieses Dokuments so definiert, dass er die Betriebscharakteristiken einer Familie von Computermodellen meint. Beispiele für spezielle Architekturen sind Macintosh-Computer, IBM-PCkompatible Computer unter Verwendung des DOS- oder Windows-Betriebssystems, Sun-Microsystems-Computer, auf denen das Betriebssystem Solaris läuft, sowie Computersysteme, die das Unix-Betriebssystem verwenden.
Die Bezeichnung architekturspezifisch (AS) ist für den Zweck dieses Dokuments so definiert, dass sie die Anforderung bezeichnet, dass der Code eines bestimmten Programms in einem Binärformat vorliegt, im Folgenden als der AS-Code bezeichnet wird, um nur auf Computersystemen mit einer speziellen Computerarchitektur ausgeführt zu werden. Programme mit einem Code, der in einer konventionellen Programmiersprache (z. B. C-Sprache) geschrieben ist und für eine spezielle Architektur (z. B. IBM-kompatibler PC) kompiliert ist, können nur auf dieser Architektur oder auf Emulatoren dieser Architektur laufen.
Die Bezeichnung architekturneutral (AN) ist für den Zweck dieses Dokuments so definiert, dass sie Programme bezeichnet, deren kompilierter Code auf einer Vielzahl von Computersystemen mit unterschiedlichen Architekturen ausgeführt werden kann. Zum Beispiel kann ein Computersystem mit einer speziellen Architektur mit einem Modul der virtuellen Maschine Java (Markenzeichen der Sun Microsystems) konfiguriert werden. Das Modul der virtuellen Maschine Java ermöglicht die Ausführung von Programmen, deren Code in der Java-Programmiersprache geschrieben und in Bytecode, der im Folgenden als Java-Bytecode bezeichnet wird, kompiliert ist, für den Befehlssatz der virtuellen Maschine Java. Java-Bytecode ist unabhängig von der spezifischen Architektur des Computersystems.
Zu wichtigen Merkmalen von Programmen mit AN-Code zählt deren Portierbarkeit. Da z. B. Programme in AN-Code auf jedem Computersystem, das dazu konfiguriert ist, den AN-Code unabhängig von der spezifischen Architektur des Computersystems auszuführen, ausgeführt werden können, können diese Programme einfach über ein Netzwerk von einem Computersystem auf ein anderes übertragen werden. Zum Beispiel können Programme, die in Java-Bytecode kompiliert worden sind, auf jedem anderen Computersystem mit einem Modul der virtuellen Maschine Java ausgeführt werden und können einfach über ein Netzwerk von einem Computersystem auf ein anderes unter Verwendung eines HotJava (Markenzeichen der Sun Microsystems)-Netzwerkkommunikationsmanagers übertragen werden.
Ein weiteres wichtiges Merkmal bezüglich der Portierbarkeit von in Java-Bytecode kompilierten Programmen ist ferner die Verifizierbarkeit solcher Programme. Im Speziellen kann das Modul der virtuellen Maschine Java in einfacher Weise verifizieren, dass diese Programme vordefinierte Integritätskriterien erfüllen. Solche Integritätskriterien beinhalten Stapel- und Datentypnutzungsbeschränkungen, welche gewährleisten, dass Java-Bytecode nicht den Stapel des Moduls der virtuellen Maschine Java überoder unterschreitet und dass alle Befehle in Java-Bytecode nur solche Daten verwenden, deren Datentypen den Datentypbeschränkungen für diese Befehle entsprechen. Als Ergebnis kann ein Programm in Java-Bytecode keine Objektzeiger schaffen und kann im Allgemeinen nicht auf Systemressourcen zugreifen, für die der Benutzer nicht explizit eine Nutzungserlaubnis erteilt hat.
Aus diesen Gründen werden Computersysteme zum Ausführen von Programmen im AN-Code konfiguriert, welche über ein Netzwerk empfangen werden. Tatsächlich kann es sein, dass solche Computersysteme in manchen Fällen nicht einmal einen Sekundärspeicher (z. B. eine Festplatte) benötigen, da die Programme direkt in den Laufzeit- (d. h. Ausführungs-) Speicher (z. B. Arbeitsspeicher (RAM)) des Computersystems geladen werden. Als ein Ergebnis wird der Benutzer eines solchen Computersystems von dem Kreislauf aus Softwarekauf, Installation, Konfiguration und Upgrade befreit, welcher zurzeit typisch für Softwareprodukte ist.
Die gerade beschriebenen Merkmale von AN-Code machen diesen insbesondere attraktiv für die Verwendung bei kleinen oder billigen Computersystemen, welche vernetzt sind und auf welche nach Bedarf AN-Code geladen wird. Solche Arten von Computersystemen können z. B. Videospiele, Personal Digital Assistants (PDAs), Mobiltelefone oder ähnliche Computersysteme oder computerbetriebene Geräte sein.
Leider laufen Programme in AN-Code jedoch langsamer als dieselben Programme in AS-Code. Zum Beispiel laufen Programme in Java-Code, welche durch ein Modul der virtuellen Maschine Java ausgeführt werden, typischerweise 2,5 bis 20 Mal so langsam wie das äquivalente Programm in AS-Code. Ein Benutzer eines Computersystems könnte es somit wünschenswert finden, den AN-Code eines über ein Netzwerk empfangenen Programms zum Ausführen auf dem Computersystem in AS-Code zu entwickeln (d. h. zu übersetzen). In diesem Fall kann das Computersystem außerdem einen Code-Erzeuger umfassen, welcher beim Empfang des AN-Codes eines Programms diesen in entsprechenden AS-Code entwickelt, um auf der speziellen Architektur des Computersystems ausgeführt zu werden.
Bei den gerade beschriebenen Computersystemen ist der Preis extrem wichtig. In der Praxis gehört zu den signifikantesten Kosten beim Bau solcher Computersysteme die Menge an Laufzeitspeicher, welche für die Ausführung von geladenen Programmen benötigt wird. Es ist daher sehr wichtig, die Menge an durch diese Computersysteme benötigtem Laufzeitspeicher zu reduzieren, da eine solche Reduktion einen starken Wettbewerbsvorteil schafft.
Leider ist AS-Code, welcher aus AN-Code entwickelt worden ist, viel größer als der originale AN-Code. Zum Beispiel ist aus Java-Bytecode entwickelter AS-Code typischerweise 2 bis 5 Mal so groß wie der Java-Bytecode. Eine feste Menge an Laufzeitspeicher kann daher wesentlich weniger kompilierten AS-Code als AN-Code aufnehmen. Wie vorher erwähnt, ist AS-Code jedoch viel schneller als der AN-Code, aus welchem er entwickelt wurde, und könnte der einzige Weg zum Erreichen einer adäquaten Leistungsfähigkeit sein.
Bei den Computersystemen des oben beschriebenen Typs kann es ferner sein, dass es nicht möglich ist, den Sekundärspeicher zu blättern. In diesem Fall könnte der entwickelte AS-Code in dem Laufzeitspeicher gecached werden und gelöscht werden, wenn sein Platz im Laufzeitspeicher benötigt wird. Soll die Ausführung des gelöschten Programms jedoch fortgesetzt werden, so muss der originale AN-Code erneut über das Netzwerk herunter geladen werden und in AS-Code entwickelt werden. Dies wirkt sich signifikant auf die Ausführungsgeschwindigkeit des Programms aus. Ferner kann selbst in Computersystemen, in welchen es möglich ist, den Sekundärspeicher zu blättern, die zum Abrufen des AS-Codes aus dem Sekundärspeicher benötigte Zeit zu sein.
In der vorliegenden Erfindung wird eine Komprimierung und dann eine Dekomprimierung des AS-Codes verwendet, um den Speicheraufwand des AS-Codes in dem Laufzeitspeicher zu reduzieren. Da dies wesentlich schneller ist, als den AS-Code zu löschen und ihn neu zu entwickeln, wird die Ausführungsgeschwindigkeit des AS-Codes durch Komprimierung und Dekomprimierung nicht signifikant beeinflusst.
ZUSAMMENFASSUNG DER ERFINDUNG
Im Stand der Technik ist das Dokument „FAIL-SAFE MESSAGE FOR INSUFFICIENT DISK SPACE", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 37, no. 4A, 1. April 1994, page 513, bekannt.
Dieses Dokument bezieht sich auf die Handhabung von Situationen unzureichenden Speicherplatzes zum Ausführen einer bestimmten Aufgabe. Die Verwendung eines Mechanismus zum Komprimieren von Dateien, welche durch vorherige automatische Komprimierung von Dateien komprimiert worden sind, ist in Zeilen 21 bis 22 gezeigt. Der letzte Absatz dieses Dokuments lehrt ferner eine automatische Dekomprimierung einer Datei. Der vierte Absatz des Dokuments lehrt eine automatische Komprimierung, wenn mehr Systemspeicher benötigt ist. Als Beispiel sind die ältesten Dateien, größten Dateien oder Dateien eines bestimmten Typs als Kriterien angegeben, um Dateien zur Komprimierung auszuwählen.
Zusammenfassend ist die vorliegende Erfindung ein Client-Computersystem und zugehöriges Verfahren in einem Computernetzwerk, über welches Programme mit Methoden in architekturneutralem Code bereitgestellt sind. Der Client-Computer ist im Stande, Programme mit reduzierten Laufzeitspeicherplatzanforderungen auszuführen, wenn die Methoden in architekturspezifischem Code vorliegen, der aus dem architekturneutralen Code der Methoden entwickelt wurde. Das Client-Computersystem umfasst einen Laufzeitspeicher, eine Kommunikationsschnittstelle, einen Netzwerkkommunikationsmanager, einen Ausführungskontroller, einen Code-Erzeuger und einen Code-Komprimierer.
Die Netzwerkkommunikationsschnittstelle empfängt die Methoden in architekturneutralem Code. Der Netzwerkkommunikationsmanager lädt den architekturneutralen Code der Methoden nach dem Empfang unkomprimiert in verfügbaren Platz im Laufzeitspeicher.
Der Code-Erzeuger entwickelt in dem Laufzeitspeicher unkomprimierten architekturspezifischen Code der Methoden von dem geladenen architekturneutralen Code der Methoden. Der Ausführungskontroller steuert/regelt die Ausführung der Programme, so dass die Methoden zu unterschiedlichen Zeiten aufgerufen und nicht aufgerufen werden.
Der Code-Komprimierer komprimiert in dem Speicher den architekturspezifischen Code der komprimierbaren der Methoden, welche nicht aufgerufen sind. Als Ergebnis wird Speicher in dem Laufzeitspeicher freigegeben. Der Code-Komprimierer dekomprimiert außerdem den architekturspezifischen Code von dekomprimierbaren der Methoden in verfügbaren Platz im Laufzeitspeicher, so dass die dekomprimierbaren der Methoden aufgerufen werden können.
In einer Ausführungsform dekomprimiert der Code-Komprimierer den komprimierten architekturspezifischen Code von dekomprimierbaren der Methoden, sobald die dekomprimierbaren der Methoden aufgerufen werden.
In einer anderen Ausführungsform dekomprimiert der Code-Komprimierer den komprimierten architekturspezifischen Code der dekomprimierbaren der Methoden nach einem vorbestimmten Zeitintervall.
In noch einer anderen Ausführungsform komprimiert der Code-Komprimierer den unkomprimierten architekturspezifischen Code der komprimierbaren der Methoden, sobald die komprimierbaren der Methoden nicht länger aufgerufen sind.
In noch einer anderen Ausführungsform komprimiert der Code-Komprimierer den unkomprimierten architekturspezifischen Code der komprimierbaren der Methoden, wenn Platz in dem Laufzeitspeicher benötigt, jedoch nicht verfügbar ist. Ferner kann das Client-Computersystem in dieser Ausführungsform außerdem eine wenigst-kürzlich-aufgerufen-Liste umfassen, welche die Methoden, die momentan nicht aufgerufen sind, in der Reihenfolge von der am wenigsten kürzlich aufgerufenen Methode zur zuletzt aufgerufenen Methode listet. Als Ergebnis sind die komprimierbaren der Methoden die am wenigsten kürzlich aufgerufenen Methoden in der wenigstkürzlich-aufgerufen-Liste mit unkomprimiertem architekturspezifischen Code, wenn Platz in dem Laufzeitspeicher benötigt, jedoch nicht verfügbar ist.
In noch einer anderen Ausführungsform löscht der Code-Komprimierer den komprimierten architekturspezifischen Code von löschbaren der Methoden aus dem Laufzeitspeicher, wenn Platz in dem Laufzeitspeicher benötigt, jedoch nicht verfügbar ist.
Als Alternative zur vorhergehenden Ausführungsform kann das Client- Computersystem ferner einen Sekundärspeicher umfassen. In diesem Fall speichert der Code-Komprimierer in dem Sekundärspeicher den komprimierten architekturspezifischen Code von speicherbaren der Methoden, wenn Platz in dem Laufzeitspeicher benötigt, jedoch nicht verfügbar ist. Der Code-Komprimierer ruft aus dem Sekundärspeicher den komprimierten architekturspezifischen Code von abrufbaren der Methoden, deren komprimierter architekturspezifischer Code dekomprimiert werden soll, ab.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Beispiele der Erfindung werden in Verbindung mit den Zeichnungen beschrieben, in welchen:
1 ist ein Blockdiagramm eines Client-Computersystems, welches die vorliegende Erfindung enthält.
2 ist ein funktionales Blockdiagramm des Betriebs des Client-Computersystems.
3 ist ein Ablaufdiagramm der Komprimierungsmethode des Client-Computersystems.
4 ist ein Ablaufdiagramm der Dekomprimierungsmethode des Client-Computersystems.
5 zeigt eine Alternative Ausführungsform des Client-Computersystems.
6 zeigt ein funktionales Blockdiagramm des Betriebs der alternativen Ausführungsform des Client-Computersystems.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Unter Bezugnahme auf 1 ist dort ein Computernetzwerk 100 gemäß der vorliegenden Erfindung gezeigt. Es enthält ein oder mehrere Client-Computersysteme 102, ein oder mehrere Server-Computersysteme 104 sowie eine Netzwerkkommunikationsverbindung 106.
Die Client-Computersysteme 102 sind mit den Server-Computersystemen 104 über eine Netzwerkkommunikationsverbindung 106 verbunden. Die Netzwerkkommunikationsverbindung kann ein lokales oder großflächiges Netzwerk, das Internet oder ein anderer Typ einer Netzwerkkommunikationsverbindung sein.
Jedes Server-Computersystem 104 enthält eine Zentraleinheit (CPU) 110, eine Benutzerschnittstelle 112, eine Netzwerkkommunikationsschnittstelle 116 sowie einen Speicher 118. Die Netzwerkkommunikationsschnittstelle ermöglicht jedem Server-Computersystem mit den Client-Computersystemen 102 über die Netzwerkkommunikationsverbindung 106 zu kommunizieren.
Der Speicher 118 jedes Server-Computersystems 104 speichert ein Betriebssystem 120, einen Netzwerkkommunikationsmanager 122 sowie Programme 145. Das Betriebssystem und die Kommunikationsmanager laufen alle auf der CPU 120. Das Betriebssystem steuert und koordiniert das Laufen des Netzwerkkommunikationsmanagers in Antwort auf Kommandos, welche durch einen Benutzer mit der Benutzerschnittstelle 112 abgegeben wurden oder durch die Netzwerkkommunikationsschnittstelle 116 über die Netzwerkkommunikationsverbindung 106 von Nutzern der Client-Computersysteme 102 empfangen wurden.
Die Programme 145 umfassen Methoden 147. Für den Zweck dieses Dokuments wird jedes diskrete Bruchstück oder Teil eines Programms, welches zu bestimmten Zeiten während der Ausführung des Programms aufgerufen und nicht aufgerufen wird, als eine Methode betrachtet.
Die Methode 147 jedes Server-Computersystems 104 enthält architekturneutralen (AN)-Code in einer AN-Sprache, welche unabhängig von der spezifischen Architektur (d. h. Plattform) des Client-Computersystems 102 ist. Diese Programme werden aus einer spezifischen Programmiersprache in den AN-Code kompiliert. In der bevorzugten Ausführungsform sind diese Programme in der Java-Programmiersprache geschrieben und in Java-Bytecode kompiliert. Ferner sind diese Programme in Objektklassen mit Methoden enthalten, welche Software-Programme bilden, die in einer objektorientierten Weise programmiert sind.
Wie später detailliert beschrieben wird, werden die Methoden 147 auf eine Benutzeranfrage hin zu den Client-Computersystemen 102 unter Verwendung des Netzwerkkommunikationsmanagers 122 übertragen. Der AN-Code dieser Methoden wird dabei als netzwerkmobiler Code angesehen.
Jedes Client-Computersystem 102 kann ein Videospiel, ein Personal Digital Assistant (PDA), ein Mobiltelefon, ein Tischcomputer oder ein anderes Computersystem oder computerbetriebenes Gerät sein, welches eine kleine Menge an Laufzeitspeicher benötigt. Ferner enthält jedes Client-Computersystem eine Zentraleinheit (CPU) 126, eine Benutzerschnittstelle 128, eine Netzwerkkommunikationsschnittstelle 132, einen Nur-Lese-Speicher (ROM) 134 sowie einen Laufzeit- (d. h. Laufzeit-) Arbeitsspeicher (RAM) 136. Die Netzwerkkommunikationsschnittstelle ermöglicht dem Client-Computersystem mit den Server-Computersystemen 104 über die Netzwerkkommunikationsverbindung 106 zu kommunizieren.
Der RAM 136 eines jeden Client-Computersystems 102 speichert ein Betriebssystem 138, einen Netzwerkkommunikationsmanager 140, ein Modul einer virtuellen Maschine 142, einen Code-Erzeuger 144 sowie einen Code-Komprimierer 146, welche alle aus dem ROM 136 geladen worden sind. Der RAM speichert außerdem Programme 145 mit Methoden 147, welche herunter geladenen AN-Code enthalten, und/oder Methoden 148, welche architekturspezifischen (AS)-Code, der aus herunter geladenem AN-Code entwickelt wurde, enthalten. Das Betriebssystem, der Netzwerkkommunikationsmanager, das Modul der virtuellen Maschine, der Code-Kompilierer, der Code-Komprimierer und Programme werden alle auf der CPU 126 ausgeführt. Das Betriebssystem steuert und koordiniert die Ausführung des Netzwerkkommunikationsmanagers, des Moduls der virtuellen Maschine, des Code-Kompilierers, des Code-Komprimierers und der Programme in Antwort auf durch einen Nutzer mit der Nutzerschnittstelle 128 gegebene Kommandos.
Wie vorher erwähnt, werden die Methoden 147, die AN-Code enthalten, von den Server-Computersystemen 104 auf eine Benutzeranforderung hin empfangen. Diese Methoden werden unter Verwendung eines Netzwerkkommunikationsmanagers 140 erhalten, welcher in der bevorzugten Ausführungsform ein HotJava-Netzwerkkommunikationsmanager ist. Der Netzwerkkommunikationsmanager lädt dann diese Methoden in den RAM 136.
Der Code-Verifizierer 151 des Moduls der virtuellen Maschine 142 verifiziert, dass der AN-Code der geladenen Methoden 147 vordefinierte Integritätskriterien erfüllt. Wie vorher erwähnt, kann dies Stapel- und Datentypnutzungsbeschränkungen umfassen, um zu gewährleisten, dass geladene Methoden nicht den Stapel des Moduls der virtuellen Maschine überschreiten oder unterschreiten können und dass alle Anweisungen nur Daten verwenden, deren Datentyp den Datentypbeschränkungen für diese Anweisungen genügen. In der bevorzugten Ausführungsform ist das Modul der virtuellen Maschine ein Modul der virtuellen Maschine Java.
Die Methoden 148, die AS-Code enthalten, enthielten ursprünglich AN-Code, der von den Server-Computersystemen 104 erhalten wurde und unter Verwendung des Netzwerkkommunikationsmanagers 140 in den RAM 136 geladen worden ist. Der originale AN-Code dieser Programme ist jedoch durch den Code-Erzeuger 144 in den AS-Code entwickelt worden. Der AS-Code ist auf der spezifischen Architektur des Client-Computers ausführbar. Wie vorher erwähnt, kann der Benutzer wünschen, dass Programme in AN-Code in AS-Code entwickelt werden, da der entwickelte AS-Code schneller ausgeführt werden kann als der entsprechende AN-Code.
Ferner wurde bei Methoden 148, die AS-Code enthalten, deren AN-Code entwickelt, wenn vordefinierte AS-Code-Entwicklungskriterien 150, die in dem RAM 136 gespeichert sind, erfüllt sind. Die AS-Code-Entwicklungskriterien werden durch den Benutzer mit der Benutzerschnittstelle 128 eingegeben und werden später vollständiger beschrieben.
Der Ausführungskontroller 153 des Moduls der virtuellen Maschine 142 steuert/regelt die Ausführung der Methoden 147 und/oder 148. Insbesondere interpretiert der Ausführer den AN-Code der Methoden 147 zum Ausführen auf einer spezifischen Architektur des Client-Computersystems 102 und ermöglicht diesen Methoden, die Methoden 148 aufzurufen, die AS-Code zum Ausführen auf der spezifischen Architektur enthalten. Die Ausführungsdaten 149, die während er Ausführung der Methoden entwickelt werden, werden in dem RAM 136 gespeichert. Sind außerdem der Netzwerkkommunikationsmanager 140, der Code-Erzeuger 144 und/oder der Code-Komprimierer 146 in AN-Code, so steuert/regelt der Ausführungskontroller auch die Ausführung dieser.
Um die RAM-Speicherplatzanforderungen des Client-Computersystems 102 gering zu halten, komprimiert und dekomprimiert der Code-Komprimierer 146 ferner den Code der Methoden 147 und/oder 148 zu verschiedenen Zeiten in den RAM 136. Dies wird für die Methoden ausgeführt, welche komprimierbar und dekomprimierbar sind, da diese jeweils vordefinierte Komprimierungs- und Dekomprimierungskriterien 152 und 154 erfüllen, die in dem RAM 136 gespeichert und durch den Benutzer mit der Benutzerschnittstelle 128 eingegeben werden. Die Komprimierungs- und Dekomprimierungskriterien werden später vollständiger beschrieben.
Der Speicherungs- und Aufrufestatus der Methoden 147 und/und 148 wird durch die Methodenstatus-Datenstrukturen 155 gepflegt. Die Methodenstatus-Datenstrukturen werden durch den Netzwerkkommunikationsmanager 140, den Ausführungskontroller 153, den Code-Erzeuger 144 und den Code-Komprimierer 146 aktualisiert.
2 zeigt ein funktionales Blockdiagramm des Betriebs eines jeden der Client-Computersysteme 102 beim Komprimieren und Dekomprimieren der Methoden 147 und/oder 148 in dem RAM 136. Zusätzlich zeigen 3 bzw. 4 die bevorzugten Komprimierungs- und Dekomprimierungsmethoden 300 und 400.
Es wird sich auf die 1 bis 3 bezogen. Wenn ein Benutzer die Ausführung eines der Programme 145 eines der Client-Computersysteme 104 anfordert, so erhält das Client-Computersystem 102 des Benutzers jede Methode 147 der angeforderten Programme von dem Server-Computersystem (Schritt 302 von 3). Dies geschieht, wenn der Benutzer ein Kommando mit der Benutzerschnittstelle 128 gibt, um das Programm von dem Server-Computersystem herunter zu laden und auszuführen. In Antwort darauf ruft das Betriebssystem 120 den Netzwerkkommunikationsmanager 140 auf, welcher eine Nachricht erzeugt, die anzeigt, dass eine solche Anfrage getätigt wurde. Die Netzwerkkommunikationsschnittstelle 132 überträgt dann die Nachricht zu dem Server-Computersystem.
Die Netzwerkkommunikationsschnittstelle 116 des Server-Computersystems 104 empfängt die übertragene Nachricht. In Antwort darauf stellt der Netzwerkkommunikationsmanager 122 des Server-Computersystems die Methoden 147 des angeforderten Programms 145 der Netzwerkkommunikationsschnittstelle bereit, welche die Methoden zum Client-Computersystem 102 des Benutzers überträgt.
Die Methoden 147, die übertragen wurden, werden durch die Netzwerkkommunikationsschnittstelle 132 des Client-Computersystems 102 des Benutzers empfangen. In Antwort darauf bestimmt der Netzwerkkommunikationsmanager 140 dann, ob ausreichend Platz in dem RAM 136 verfügbar ist, um die empfangenen Methoden (Entscheidungsschritt 304 von 3) zu laden. Wenn dies der Fall ist, lädt der Netzwerkkommunikationsmanager den AN-Code dieser Methoden unkomprimiert in den verfügbaren Platz in dem Speicher (Schritt 306 von 3). Als ein Ergebnis werden diese Methoden zusammen mit vorher geladenen Methoden 147 von anderen Programmen 145 in den Speicher geladen. Beim Laden dieser Methoden aktualisiert der Netzwerkkommunikationsmanager die Methodenspeicherungs-Statustabelle 200 der Methodenstatus-Datenstruktur 155, um die Methoden und die zugehörigen Zeiger auf die durch diese Methoden belegten Speicherplätze in dem RAM 136 zu identifizieren. Außerdem aktualisiert der Netzwerkkommunikationsmanager die Methodenstatustabelle, um anzuzeigen, dass der AN-Code der Methoden unkomprimiert (U) ist.
Der Netzwerkkommunikationsmanager 140 ruft dann den Code-Verifizierer 151 des Moduls der virtuellen Maschine 142 auf. In Antwort darauf verifiziert der Code-Verifizierer, dass der AN-Code der Methoden 147, die gerade geladen wurden, den vorher diskutierten, vordefinierten Integritätskriterien genügen (Schritt 307 von 3).
Der Netzwerkkommunikationsmanager 140 bestimmt dann, ob der AN-Code von einer der Methoden 147, die gerade geladen wurden, in AS-Code kompiliert werden soll (Entscheidungsschritt 308 von 3). Dies geschieht basierend auf den AS-Code-Entwicklungskriterien 150. Wie der Fachmann erkennen wird, kann der Benutzer AS-Code-Entwicklungskriterien aus einem breiten Bereich von Optionen sowie basierend auf einer Anzahl von für das Client-Computersystem des Benutzers spezifischen Zuständen auswählen und/oder einstellen. Zum Beispiel können die AS-Code-Entwicklungskriterien angeben, dass der AN-Code von allen herunter geladenen Methoden in AS-Code entwickelt werden soll, wenn diese Methoden geladen werden, oder dass bei keiner der herunter geladenen Methoden mit AN-Code der AN-Code in AS-Code entwickelt werden soll, wenn diese geladen werden, oder dass nur bei den herunter geladenen Methoden mit AN-Code spezifischer Größe oder spezifischem Typ, deren AN-Code in AS-Code entwickelt werden soll, wenn sie geladen werden.
Soll bei einer der Methoden 147, die gerade geladen wurden, deren AN-Code in AS-Code entwickelt werden, so ruft der Netzwerkkommunikationsmanager den Code-Erzeuger 144 auf. Der Code-Erzeuger bestimmt, ob genug Platz im Speicher 136 vorhanden ist, um den AN-Code dieser Methoden in AS-Code zu entwickeln (Entscheidungsschritt 310 von 31. Ist dies der Fall, so entwickelt der Code-Erzeuger den AS-Code dieser Methoden in dem verfügbaren Speicher (Schritt 312 von 3) und aktualisiert die Zeiger in der Methodenspeicher-Statustabelle 200, so dass sie auf die Plätze zeigen, die durch den entwickelten AS-Code eingenommen werden. Als ein Ergebnis werden diese Methoden zusammen mit anderen vorher herunter geladenen Methoden, deren AN-Code in AS-Code entwickelt wurde, als die Methoden 148, die AS-Code enthalten, in dem RAM gespeichert.
Das Programm 145 mit den Methoden 147, die soeben geladenen AN-Code enthalten, und/oder den Methoden 148, die soeben geladenen und in AS-Code entwickelten AS-Code enthalten, wird dann unter der Steuerung/Regelung des Ausführers (Schritt 314 in 3) zusammen mit etwaigen vorher geladenen Programmen 145 ausgeführt. Wie vorher erwähnt, interpretiert der Ausführungskontroller den AN-Code der Methoden 147 zum Ausführen auf der spezifischen Architektur des Client-Computersystems 102 des Benutzers und ermöglicht diesem Programm, die Methoden 148, die AS-Code enthalten, zur Ausführung auf der spezifischen Architektur aufzurufen.
Jede der geladenen Methoden 147 und/oder 148 kann zu verschiedenen Zeiten nicht aufgerufen sein, da sie in einen Schlafmodus, etc. versetzt sein kann. Wenn der Programmausführungskontroller bestimmt, dass dies eingetreten ist, so fügt er die Methoden zur wenigst-kürzlich-aufgerufen-Liste (LRI) 202 der Methodenstatus-Datenstrukturen 155 hinzu, um anzuzeigen dass sie momentan nicht aufgerufen sind. Die Methoden in der LRI-Liste sind von der zuletzt aufgerufenen zur am wenigsten kürzlich aufgerufenen gelistet.
Wie schon vorher angedeutet, wird, um die Platzanforderungen des RAMs 136 zu reduzieren, der Code jeder geladenen Methode 147 und/oder 148, für die die vordefinierten Komprimierungskriterien 152 erfüllt sind, durch den Code-Komprimierer 146, komprimiert. In der bevorzugten Ausführungsform gibt das Komprimierungskriterium an, dass der Code einer komprimierbaren Methode 147 oder 148 zu einer Zeit komprimiert werden soll, wenn (1) im RAM 136 Platz benötigt, jedoch nicht verfügbar ist und (2) die Methode, die am wenigsten kürzlich aufgerufene der Methoden in der LRI-Liste 202, deren Code noch nicht komprimiert worden ist, ist.
Wenn der Netzwerkkommunikationsmanager 140 bestimmt, dass im RAM 136 kein Platz verfügbar ist, um eine oder mehrere der Methoden 147 zu laden, die durch die Server-Computersysteme 104 empfangen worden sind (Entscheidungsschritt 304 von 3), so ruft er den Code-Komprimierer 146 auf. In Antwort darauf komprimiert der Code-Komprimierer den Code, der am wenigsten kürzlich aufgerufenen Methode(n) in der LRI-Liste 202, bis ausreichend Speicherplatz zur Verfügung gestellt worden ist (Schritt 316 von 3). Der Code-Komprimierer aktualisiert außerdem die Methodenspeicher-Statustabelle 200, um den/die entsprechenden Zeiger auf den Speicherplatz/die Speicherplätze des komprimierten Codes der Methode(n) zu identifizieren und um anzuzeigen, dass der Code der Methode(n) komprimiert worden ist (C). Der Netzwerkkommunikationsmanager lädt dann die Methode(n), für welche Speicherplatz zur Verfügung gestellt worden ist, wie vorher beschrieben, in den verfügbaren Speicher (Schritt 306 von 3).
Der Code-Komprimierer 146 kann irgendeine schnelle Datenkomprimierungstechnik verwenden, die dem Fachmann gut bekannt ist. Der Code-Komprimierer kann außerdem getrennte Komprimierungstechniken für eine optimale Komprimierung des AN-Codes der Methoden 147 und des AS-Codes der Methoden 148 verwenden.
Wenn der Code-Erzeuger zum Kompilieren einer oder mehrerer soeben geladenen Methoden 147 Platz in dem RAM benötigt (Entscheidungsschritt 310 von 3), so ruft der Code-Erzeuger 144 zusätzlich den Code-Komprimierer 146 auf. Wie in dem Fall soeben geladener Methoden komprimiert der Code-Komprimierer den Code der am wenigsten kürzlich ausgeführten Methoden in der LRI-Liste 202, bis ausreichend Speicher zur Verfügung gestellt worden ist (Schritt 318 von 3) und aktualisiert dabei die Methodenspeicherstatustabelle 200, um den/die entsprechenden Zeiger auf den Speicherplatz/die Speicherplätze des komprimierten Codes der Methode(n) zu identifizieren und anzuzeigen, dass der Code der Methode(n) komprimiert worden ist (C). Der Code-Erzeuger entwickelt dann in dem verfügbaren Speicherplatz den AN-Code der Methoden, für welche der Speicherplatz zur Verfügung gestellt wurde, wie vorher beschrieben (Schritt 312 von 3).
Während die geladenen Methoden 147 und/oder 148 aufgerufen sind, erzeugen sie außerdem Ausführungsdaten. Für jede dieser Methoden, für welche der Ausführungskontroller 153 bestimmt, dass sie aufgerufen sind (Entscheidungsschritt 320 in 3), und für welche Speicherplatz in dem RAM 136 zum Speichern von Ausführungsdaten zur Verfügung gestellt wurde (Entscheidungsschritt 322), speichert der Ausführungskontroller die Ausführungsdaten in dem RAM (Schritt 324 von 3).
Für jede der geladenen Methoden 147 und/oder 148, für welche der Ausführer 153 bestimmt, dass sie ausführbar sind (Entscheidungsschritt 320 von 3), und für welchen Speicherplatz in dem RAM nicht verfügbar, jedoch benötigt ist, um Ausführungsdaten zu speichern (Entscheidungsschritt 322), ruft der Ausführer jedoch den Code-Komprimierer 146 auf. Wie in den vorangegangenen Situationen, in welchen Speicherplatz in dem RAM benötigt wurde, komprimiert der Code-Komprimierer den Code der am wenigsten kürzlich ausgeführten Methoden in der LRI-Liste 202, bis ausreichend Speicherplatz zur Verfügung gestellt ist (Schritt 326 von 3). Wie bereits beschrieben, aktualisiert der Code-Komprimierer außerdem die Methodenspeicher-Statustabelle 200, um den entsprechenden Zeiger/die entsprechenden Zeiger auf den Speicherplatz/die Speicherplätze des komprimierten Codes der Methode(n) zu identifizieren und um anzuzeigen, dass der Code der Methode(n) komprimiert worden ist (C). Der Ausführungskontroller speichert dann, wie bereits beschrieben, die Ausführungsdaten in dem zur Verfügung gestellten Speicherplatz in dem RAM (Schritt 324 von 3) und die Ausführung des Programms mit der Methode/den Methoden, deren Ausführungsdaten gespeichert wurden, wird fortgesetzt (Schritt 314 von 3).
Unter Bezugnahme auf die 1, 2 und 4 wird, wenn Speicherplatz in dem RAM 136 verfügbar ist, jede geladene Methode 147 und/oder 148, welche komprimiert ist und für welche die vordefinierten Dekomprimierungskriterien 154 erfüllt sind, durch den Code-Komprimierer 146 dekomprimiert. In der bevorzugten Ausführungsform geben die Dekomprimierungskriterien zum Dekomprimieren des Codes einer dekomprimierbaren Methode einfach an, dass der Code der Methode komprimiert ist und zu einer Zeit, wenn die Methode wieder aufgerufen werden soll, wieder dekomprimiert werden soll.
Immer dann, wenn der Ausführungskontroller 153 bestimmt, dass eine der geladenen Methoden 147 und/oder 148 aufgerufen werden soll (Entscheidungsschritt 402 von 4), bestimmt er daher, ob der Code dieser Methode komprimiert ist (Entscheidungsschritt 404 von 4). Dies wird aus der Methodenspeicher-Statustabelle 200 bestimmt. Wenn der Code der Methode nicht komprimiert ist, so wird die Methode durch den Ausführungskontroller aufgerufen (Schritt 406 von 4). Ist sie nicht mehr aufgerufen, so kann ihr Code durch den Code-Komprimierer 146 in der bereits beschriebenen Weise komprimiert werden.
Ist jedoch der Code der Methode 147 oder 148, die aufgerufen werden soll, komprimiert, so ruft der Ausführungskontroller den Code-Komprimierer 146 auf, um den Code der Methode zu dekomprimieren. Der Code-Komprimierer bestimmt, ob genug Speicherplatz in dem RAM 136 verfügbar ist, um den Code der Methode zu dekomprimieren (Entscheidungsschritt 408 von 4). Ist ausreichend Speicherplatz verfügbar, so dekomprimiert der Code-Komprimierer den Code der Methode in den verfügbaren Speicherplatz (Schritt 410 von 4). Dabei aktualisiert er die Methodenspeichertabelle 200, um den entsprechenden Zeiger/die entsprechenden Zeiger zu dem Speicherplatz/den Speicherplätzen des unkomprimierten Codes zu identifizieren und um anzuzeigen, dass der Code der Methode unkomprimiert ist (U).
Ist jedoch nicht ausreichend Speicherplatz verfügbar, so komprimiert der Code-Komprimierer 146 den Code der am wenigsten kürzlich ausgeführten Methode(n) in der LRI-Liste 202, deren Code noch nicht komprimiert worden ist, so lange, bis Speicherplatz zur Verfügung gestellt ist (Schritt 412 von 4). Dies geschieht auf die bereits beschriebene Weise. Wenn der Speicherplatz zur Verfügung gestellt wurde, wird der Code der Methoden 147 oder 148, die dekomprimiert werden sollen, durch den Code-Komprimierer in den verfügbaren Speicherplatz dekomprimiert und danach durch den Ausführungskontroller 153 in der soeben beschriebenen Weise aufgerufen (Schritte 410 und 406 in 4).
Im Hinblick auf das Vorstehende ist klar, dass die vorliegende Erfindung eine Reduzierung des Laufzeitspeicherplatzes bei Verbesserung der Ausführungsgeschwindigkeit bereitstellt. Dies ist auf die Tatsache zurückzuführen, dass durch ein Komprimieren der geladenen Methoden 147 und/oder 148 diese nicht aus dem RAM 136 gelöscht und erneut von den Server-Computersystemen 104 herunter geladen werden müssen, wenn Speicherplatz im RAM benötigt wird. Ferner wird in dem Fall, dass die Methoden AS-Code enthalten, die Ausführungsgeschwindigkeit weiter verbessert, da diese Methoden nicht erneut herunter geladen und erneut entwickelt werden müssen. Der Fachmann wird jedoch erkennen, dass andere alternative Ausführungsformen implementiert werden könnten, um ähnliche Vorteile bereitzustellen.
Insbesondere gaben die bereits beschriebenen Komprimierungskriterien 152 an, dass der Code der am wenigsten kürzlich aufgerufenen Methode(n) 147 und/oder 148 mit unkomprimiertem Code komprimiert wurde, wenn Speicherplatz in dem RAM 136 benötigt, jedoch nicht verfügbar war. Die Komprimierungskriterien können jedoch von dem Benutzer aus einem breiten Bereich von Optionen und basierend auf einer Anzahl von für das Client-Computersystem 102 des Benutzers spezifischen Zuständen ausgewählt werden. Zum Beispiel können die Komprimierungskriterien einfach angeben, dass der Code einer jeden Methode komprimiert werden soll, sobald das Programm nicht mehr aufgerufen ist. Oder sie können angeben, dass der Code bestimmter Methoden verlangsamt komprimiert werden soll, wenn immer Zeit dafür zur Verfügung steht. Als eine zusätzliche Abänderung einer der vorhergehenden können die Komprimierungskriterien angeben, dass nur der Code von Methoden einer bestimmten Größe oder eines bestimmten Typs komprimiert werden soll.
Ferner gaben die Dekomprimierungskriterien 154, wie bereits gesagt, an, dass für eine Methode 147 oder 148, deren Code komprimierter Code ist, ihr Code dekomprimiert wurde, sobald die Methode aufgerufen werden sollte. Die Dekomprimierungskriterien könnten jedoch angeben, dass der komprimierte Code dekomprimiert wird, nachdem eine vorbestimmte Zeitdauer abgelaufen ist. In diesem Fall würde der Datenkomprimierer einen Zeitnehmer zum Stoppen des Zeitintervalls enthalten. In einem Beispiel könnte diese Technik für eine Methode verwendet werden, welche für eine bekannte Zeitdauer in einen Schlafzustand versetzt wurde, so dass die Methode für diese Zeitdauer komprimiert wird und dann, wenn sie geweckt werden soll oder kurz vorher, dekomprimiert wird. In einem anderen Beispiel könnte die Technik für eine Methode verwendet werden, welche auf Daten wartet, wobei die Zeitdauer, während der die Methode komprimiert wird, so gewählt wird, dass man vorhersagt, wenn die Daten für die Methode verfügbar werden.
In einer anderen Ausführungsform können die Komprimierungskriterien 152 außerdem Löschkriterien beinhalten, wann die geladenen Methoden 147 und/oder 148 aus dem RAM 136 gelöscht werden sollen. Zum Beispiel können die Löschkriterien angeben, dass, wenn sich in dem Speicher keine geladenen Methoden mehr befinden, die nicht aufgerufen sind, die am wenigsten kürzlich aufgerufene Methode/aufgerufenen Methoden in der LRI-Liste 202 mit komprimiertem Code löschbar sind und aus dem RAM 136 gelöscht werden sollen, bis ausreichend Platz zur Verfügung gestellt ist. Als Ergebnis muss der Netzwerkkommunikationsmanager, wenn eine Methode aus dem RAM gelöscht ist und danach wieder aufgerufen werden soll, die Methode von dem Server-Computersystem 104, dass die Methode in der bereits diskutierten Weise bereitstellte, erneut herunter laden. Der Ausführungskontroller 153 aktualisiert die Methodenspeicher-Statustabelle 200 durch Entfernen der Verweise zu allen gelöschten Methoden.
Ferner können in Abwandlung zur soeben beschriebener Ausführungsform die AS-Code-Entwicklungskriterien 150 angeben, dass der AN-Code von Methoden 148, deren AN-Code in AS-Code entwickelt worden ist, in dem RAM 136 zusammen mit dem entwickelten AS-Code gehalten werden soll. Dies würde so geschehen, dass der AN-Code der Methode erneut in AS-Code der Methode entwickelt werden kann, im Falle, dass der AS-Code der Methode aus dem RAM gelöscht worden ist. Dies wird die Zeit, die für ein erneutes Herunterladen des AN-Codes der Methode von dem Server-Computersystem benötigt wird, einsparen. Zusätzlich könnte der AN-Code in dem RAM komprimiert werden, bis er für die Neuentwicklung in AS-Code benötigt wird.
In einer anderen Abwandlung der soeben beschriebenen Ausführungsform würde der herunter geladene AN-Code der Methoden 148 anfänglich unter der Steuerung/Regelung des Ausführungskontrollers 153 ausgeführt. Dann würde der Ausführungskontroller Statistiken basierend auf dem Laufzeitverhalten des AN-Codes erstellen und den AN-Code in AS-Code entwickeln, wenn die aufgestellten Statistiken bestimmten Schwellwertkriterien in den AS-Code-Entwicklungskriterien 150 genügen. Zum Beispiel kann der Ausführungskontroller einen Zähler für die Anzahl führen, wie oft der AN-Code ausgeführt wird. Wenn dieser Zähler einmal eine Grenzzahl durchlaufen hat, würde der Ausführungkontroller den Code-Erzeuger 144 aufrufen, um den AN-Code in AS-Code zu entwickeln.
Da ein Löschen von geladenen Methoden 147 und/oder 148 aus dem RAM 136 im Hinblick auf die Ausführungsgeschwindigkeit kostspielig ist, kann ein Sekundärspeicher 500 verwendet werden, um die Methoden, die ansonsten gelöscht werden würden, wie in 5 und 6 gezeigt, zu speichern. In diesem Fall würden die bereits diskutierten Komprimierungskriterien 152 Sekundärspeicherkriterien 156 umfassen, welche den soeben diskutierten Löschkriterien ähnlich wären und dazu verwendet werden würden, Methoden, welche speicherbar sind, da sie die Sekundärspeicherkriterien erfüllen, zu speichern. In diesem Fall würde der Code-Komprimierer 146 jedoch die Zeiger in der Methodenspeicher-Statustabelle 200 aktualisieren, damit diese auf die Methoden in dem Sekundärspeicher zeigen. Für die Methoden, welche abrufbar sind in dem Sinne, dass ihr Code komprimiert ist, in dem Sekundärspeicher gespeichert ist und dekomprimiert werden soll, würde der Code der Methoden ferner aus dem Sekundärspeicher abgerufen und dann in dem RAM 136 auf die bereits beschriebene Weise dekomprimiert werden.
In einer Ausführungsform, in welcher das Client-Computersystem 102 einen Sekundärspeicher 500 umfasst (z. B. einen vernetzten Tischcomputer), könnten die Methoden 147 außerdem von den Server-Computersystemen 104 in den Sekundärspeicher herunter geladen werden. Diese Methoden könnten dann statt von den Server-Computersystemen 104 direkt von dem Sekundärspeicher in den RAM 136 geladen werden. In einer solchen Ausführungsform könnten zusätzlich das Betriebssystem 138, der Netzwerkkommunikationsmanager 140, das Modul der virtuellen Maschine 142 sowie der Code-Komprimierer 146 in dem Sekundärspeicher gespeichert werden und von dort in den RAM geladen werden.
In einer anderen Ausführungsform könnten das Betriebssystem 138, der Netzwerkkommunikationsmanager 140, das Modul der virtuellen Maschine 142, der Code-Erzeuger 144 sowie der Code-Komprimierer 146 von einem der Server-Computersysteme 104 in den RAM 136 des Client-Computersystems 102 herunter geladen werden. Dies würde in einer ähnlichen Weise geschehen, wie bereits für die Methoden 147 eines Server-Computersystems beschrieben.

Claims

Client-Computersystem zur Verwendung in einem Computernetzwerk, über welches Programme mit Methoden in architekturneutralem Code bereitgestellt sind, wobei das Client-Computersystem dazu vorgesehen ist, die Programme mit reduzierten Laufzeitspeicherplatz-Anforderungen auszuführen, wenn die Methoden in aus dem architekturneutralen Code der Methoden erzeugtem, architekturspezifischem Code vorliegen, und wobei das Client-Computersystem ferner umfasst: einen Laufzeitspeicher; eine Netzwerkkommunikationsschnittstelle, welche die Methoden in architekturneutralem Code empfängt; einen Netzwerkkommunikationsmanager, welcher den architekturneutralen Code der Methoden bei Erhalt unkomprimiert in verfügbaren Platz im Laufzeitspeicher lädt; einen Codeerzeuger, welcher in dem Laufzeitspeicher unkomprimierten, architekturspezifischen Code der Methoden aus dem geladenen, architekturneutralen Code der Methoden erzeugt; einen Ausführungskontroller, welcher die Ausführung der Programme steuert/regelt, wobei die Methoden zu verschiedenen Zeiten aufgerufen und nicht aufgerufen sind; einen Codekomprimierer, um (A) in dem Laufzeitspeicher den unkomprimierten, architekturspezifischen Code von komprimierbaren der Methoden, die nicht aufgerufen sind, zu komprimieren, wodurch in dem Laufzeitspeicher Platz verfügbar gemacht wird, und um (B) den komprimierten, architekturspezifischen Code von dekomprimier baren der Methoden in verfügbaren Platz im Laufzeitspeicher zu dekomprimieren, so dass die dekomprimierbaren der Methoden aufgerufen werden können.
Client-Computersystem nach Anspruch 1, wobei der Codekomprimierer den komprimierten, architekturspezifischen Code der dekomprimierbaren der Methoden dekomprimiert, sobald die dekomprimierbaren der Methoden aufgerufen werden sollen.
Client-Computersystem nach Anspruch 1, wobei der Codekomprimierer den komprimierten, architekturspezifischen Code der dekomprimierbaren der Methoden nach einem vorbestimmten Zeitintervall dekomprimiert.
Client-Computersystem nach Anspruch 1, 2 oder 3, wobei der Codekomprimierer den unkomprimierten, architekturspezifischen Code der komprimierbaren der Methoden komprimiert, sobald die komprimierbaren der Methoden nicht mehr aufgerufen sind.
Client-Computersystem nach Anspruch 1, 2 oder 3, wobei der Codekomprimierer den unkomprimierten, architekturspezifischen Code der komprimierbaren der Methoden komprimiert, wenn Platz im Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist.
Client-Computersystem nach einem der Ansprüche 1 bis 5, ferner umfassend: eine Wenigst-kürzlich-aufgerufen-Liste, welche diejenigen der Methoden, die momentan nicht aufgerufen sind, in der Reihenfolge von der am wenigsten kürzlich aufgerufenen Methode zur zuletzt aufgerufenen Methode auflistet; wobei die komprimierbaren der Methoden die am wenigsten kürzlich aufgerufenen Methoden in der Wenigst-kürzlich-aufgerufen- Liste mit unkomprimiertem, architekturspezifischem Code sind, wenn Platz im Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist.
Client-Computersystem nach einem der Ansprüche 1 bis 6, wobei der Codekomprimierer den komprimierten, architekturspezifischen Code von löschbaren der Methoden von dem Laufzeitspeicher löscht, wenn Platz im Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist.
Client-Computersystem nach einem der Ansprüche 1 bis 7, ferner umfassend: einen Sekundärspeicher, wobei der Codekomprimierer (A) den komprimierten, architekturspezifischen Code von speicherbaren der Methoden in dem Sekundärspeicher speichert, wenn Platz in dem Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist, und (B) von dem Sekundärspeicher den komprimierten, architekturspezifischen Code von abrufbaren der Methoden abruft, deren komprimierter, architekturspezifischer Code dekomprimiert werden soll.
Verfahren zur Verwendung in einem Computernetzwerk, über welches Programme mit Methoden in architekturneutralem Code bereitgestellt sind, wobei das Verfahren dazu vorgesehen ist, die Programme mit reduzierten Laufzeitspeicherplatz-Anforderungen auszuführen, wenn die Methoden in aus dem architekturneutralen Code der Methoden erzeugtem, architekturspezifischem Code vorliegen, und wobei das Verfahren die Schritte umfasst: Bereitstellen eines Laufzeitspeichers; Aufnehmen der Programme in architekturneutralem Code; Laden des architekturneutralen Codes der Methoden, wenn sie empfangen werden, unkomprimiert in verfügbaren Platz im Laufzeitspeicher; Erzeugen von unkomprimiertem, architekturspezifischem Code der Methoden aus dem geladenen, architekturneutralen Code der Methoden im Laufzeitspeicher; Ausführen der Programme, wodurch die Methoden zu unterschiedlichen Zeiten aufgerufen und nicht aufgerufen werden; Komprimieren des unkomprimierten, architekturspezifischen Codes von komprimierbaren der Methoden, welche nicht aufgerufen sind, wodurch in dem Laufzeitspeicher Platz verfügbar gemacht wird; und Dekomprimieren des komprimierten, architekturspezifischen Codes von dekomprimierbaren der Methoden in verfügbaren Platz im Laufzeitspeicher, so dass die dekomprimierbaren der Methoden aufgerufen werden können.
Verfahren nach Anspruch 9, wobei der Dekomprimierungsschritt enthält: Dekomprimieren des komprimierten, architekturspezifischen Codes der dekomprimierbaren der Methoden, sobald die dekomprimierbaren der Methoden aufgerufen werden sollen.
Verfahren nach Anspruch 9, wobei der Dekomprimierungsschritt enthält: Dekomprimieren des komprimierten, architekturspezifischen Codes der dekomprimierbaren der Methoden nach einem vorbestimmten Zeitintervall.
Verfahren nach Anspruch 9, 10 oder 1 1, wobei der Komprimierungsschritt enthält: Komprimieren des unkomprimierten, architekturspezifischen Codes der komprimierbaren der Methoden, sobald die komprimierbaren der Methoden nicht mehr aufgerufen sind.
Verfahren nach Anspruch 9, 10 oder 1 1, wobei der Komprimierungsschritt enthält: Komprimieren des architekturspezifischen Codes der komprimierbaren der Methoden, wenn Platz im Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist.
Verfahren nach einem der Ansprüche 9 bis 13, ferner umfassend die Schritte: Bereitstellen einer Wenigst-kürzlich-ausgeführt-Liste, welche die Methoden, die momentan nicht aufgerufen sind, in der Reihenfolge von der am wenigsten kürzlich aufgerufenen Methode zur zuletzt aufgerufenen Methode auflistet, wobei die komprimierbaren der Methoden die am wenigsten kürzlich aufgerufenen Methoden in der Wenigst-kürzlich-aufgerufen-Liste mit unkomprimiertem, architekturspezifischem Code sind, wenn Platz im Laufzeitspeicher benötigt wird, jedoch nicht vefügbar ist.
Verfahren nach einem der Ansprüche 9 bis 14, ferner umfassend den Schritt eines Löschens des komprimierten, architekturspezifischen Codes von löschbaren der Programme aus dem Laufzeitspeicher, wenn Platz in dem Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist.
Verfahren nach einem der Ansprüche 9 bis 15, ferner umfassend die Schritte: Bereitstellen eines Sekundärspeichers; Speichern des komprimierten, architekturspezifischen Codes von speicherbaren der Methoden in dem Sekundärspeicher, wenn Platz in dem Laufzeitspeicher benötigt wird, jedoch nicht verfügbar ist; und Abrufen des komprimierten, architekturspezifischen Codes von abrufbaren der Methoden, deren komprimierter, architekturspezifischer Code dekomprimiert werden soll, aus dem Sekundärspeicher.