DE69930855T2

DE69930855T2 - Verfahren und vorrichtung zur durchführung einer deterministischen speicherzuordnungsantwort in einem computer-system

Info

Publication number: DE69930855T2
Application number: DE69930855T
Authority: DE
Inventors: Nedim San Francisco FRESKO; R. Dean Boulder Creek LONG
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-07-24
Filing date: 1999-07-23
Publication date: 2006-11-23
Anticipated expiration: 2019-07-24
Also published as: EP1101167A1; JP2002521749A; ATE323305T1; DE69930855D1; WO2000005652A1; US6349312B1; EP1101167B1

Description

Hintergrund
Die vorliegende Erfindung bezieht sich allgemein auf Computersysteme und genauer gesagt auf ein Verfahren und eine Vorrichtung zum Erzielen einer deterministischen Speicherzuordnungsantwort in einem Computersystem.
In vielen modernen Computersystemen wird Speicher bzw. Speicherraum, der für die Ausführung von Programmkomponenten, wie zum Beispiel von Objekten, benötigt wird, zur Laufzeit (während des laufenden Programms) anstatt zur Zeit der Kompilierung zugeordnet. In solchen Systemen wird Speicher, wenn immer ein Objekt während der Ausführung erzeugt oder instantiiert wird, Speicher aus einem Speicherhaufen dynamisch zugeordnet, um das Objekt aufzunehmen. Dieser Speicher kann verwendet werden, um Daten zu halten, die zu dem Objekt gehören, oder um Vorgänge durchzuführen, die aufgrund des Objektes erforderlich sind. Wenn der Speicher nicht mehr benötigt wird (wenn beispielsweise das Objekt überflüssig wird), wird der Speicher an den Haufen zurückgegeben, so daß er für andere Objekte verwendet werden kann. Unterschiedliche Verfahrensweisen existieren für das Freigeben von Speicher zurück an einen Speicherhaufen. Eine übliche Verfahrensweise wird als Müllsammlung (garbage collection – GC) bezeichnet.
Bei der GC wird die Freigabe von Speicher zurück an einen Speicherhaufen durch das System gesteuert. D.h., der Benutzer (d.h. der Entwickler der Anwendung) steuert bzw. kontrolliert, wann ein Objekt instantiiert wird und damit auch, wann Speicher zugeordnet wird, jedoch ist es das zugrundeliegende System, das steuert bzw. kontrolliert, wann die Speicherzuordnung aufgehoben wird und der Speicher an den Haufen zurück freigegeben wird. Typischerweise wird ein GC-Vorgang ausgelöst, wenn der Betrag an freiem Speicherraum in dem Haufen unter einen gewissen Schwellwert absinkt. Diese Bestimmung wird typischerweise zum Zeitpunkt der Zuordnung für eine neue Objektinstanz vorgenommen. Ein Speicherzuordnungsvorgang kann also (tut es jedoch nicht immer) einen GC-Vorgang auslösen. Wenn der GC-Mechanismus ausgelöst wird, so folgt er typischerweise einem Ablauf, um festzustellen, welche Objektinstanzen durch das aktuelle Programm erreicht werden können. Alle Speicherräume, die zu solchen Objektinstanzen gehören, werden als aktiv markiert und werden erhalten. Alle anderen Speicherräume (die vermutlich zu Objekten gehören, die durch das aktuelle Programm nicht mehr erreichbar sind und damit überflüssig sind) werden eingefangen und an den Haufen zurück freigegeben. Auf diese Weise sammelt der GC-Mechanismus die „weggeworfenen" bzw. „überflüssigen" Speicherräume und gibt sie zurück an den Haufen.
Wie oben erwähnt, kann ein Speicherzuordnungsvorgang einen GC-Vorgang auslösen. Wegen dieser Möglichkeit kann die Zeit, die benötigt wird, um eine Speicherzuordnung durchzuführen, von Zuordnung zu Zuordnung in hohem Maß variieren. Zur Veranschaulichung sei angenommen, daß, wenn eine erste Speicherzuordnungsanforderung verarbeitet wird, der in dem Haufen frei verfügbare Raum oberhalb eines gewissen GC-Schwellwertes liegt; demnach ist kein GC-Vorgang er forderlich. Im Ergebnis wird die erste Zuordnung während eines Zeitbetrags X durchgeführt. Nun sei jedoch angenommen, daß, wenn eine nachfolgende Speicherzuordnungsanforderung verarbeitet wird, der in dem Haufen frei verfügbare Raum unterhalb des Schwellwertes abgesunken ist. In diesem Fall muß ein GC-Vorgang durchgeführt werden, bevor die nachfolgende Speicherzuordnung ausgeführt werden kann. Daher beträgt die Zeit, die erforderlich ist, um die nachfolgende Speicherzuordnung durchzuführen X + GCT, wobei GCT die Zeit ist, die erforderlich ist, um den GC-Vorgang durchzuführen. Da GCT im Vergleich zu X beträchtlich ist, ist auch der Zeitunterschied zwischen den beiden Speicherzuordnungsvorgängen sehr beträchtlich.
Während das Auslösen eines GC-Vorgangs ein Hauptfaktor bei der Verursachung der Variation von Speicherzuordnungszeiten ist, ist dies nicht der einzige Faktor. Andere Faktoren, wie zum Beispiel Speicherfragmentierung, können ebenfalls zu dieser Varianz beitragen. Wenn der Speicher in einem Haufen zusammenhängend ist, so wird weniger Zeit benötigt, um Speicher zuzuordnen, als wenn der Haufen in starkem Maß fragmentiert ist. Das Ausmaß der Fragmentierung des Haufens kann also die Zuordnungszeiten beeinflussen. Diese und andere Faktoren können bewirken, daß Speicherzuordnungszeiten von Zuordnung zu Zuordnung variieren.
In einigen Implementierungen ist es wichtig, daß Speicherzuordnungsvorgänge deterministisch sind, d.h. daß sie jedesmal, wenn der Vorgang durchgeführt wird, im wesentlichen immer dieselbe Zeit benötigen oder daß sie zumindest vorhersagbare Zuordnungszeiten haben. In einer Echtzeitanwendung ist es beispielsweise zwingend, daß Speicherzuordnungen deterministisch sind. Wegen der Möglichkeit großer Variationen in den Speicherzuordnungszeiten kann der typische Zuordnungs-Müllsammelmechanismus in derartigen Implementierungen nicht verwendet werden. Dementsprechend wird ein verbesserter Mechanismus benötigt.
Die EP-A-473 802 offenbart ein Computersystem mit erweitertem virtuellen Speicher, welcher Raum für parallele Programmausführungen in zuvor zugeordneten Partitionen gewährleistet. Das System unterstürzt auch dynamische Partitionen, die für eine bestimmte auszuführende Aufgabe erzeugt werden und deren Zuordnung dann aufgehoben werden kann, nachdem die Aufgabe beendet ist, um den Speicherbereich für die nachfolgende Verwendung freizugeben.
Zusammenfassung der Erfindung
Die vorliegende Erfindung stellt ein Verfahren, ein System und ein Computerprogrammprodukt bereit, um zu ermöglichen, daß Speicherzuordnungsvorgänge deterministisch sind. Die vorliegende Erfindung beruht zumindest teilweise auf der Beobachtung, daß der Determinismus erreicht werden kann, indem zuerst ein zusammenhängender Speicherraum vorab zugeordnet wird und dann dieser Speicherraum verwendet wird, um die tatsächlichen Speicherzuordnungsvorgänge durchzuführen. Da die Speicherzuordnungsvorgänge unter Verwendung von Speicherraum durchgeführt werden, der bereits zugeordnet worden ist, wird sichergestellt, daß die Zuordnungsvorgänge keinen GC-Vorgang auslösen. Da außerdem der vorab zugeordnete Speicherraum zusammenhängend ist, gibt es keine Fragmentierungsprobleme. Die vorliegende Erfindung beseitigt daher zwei Hauptursachen nicht konstanter Zuordnungszeiten. Indem dies geschieht, macht die vorliegende Erfindung es möglich, in einem dynamischen Speicherzuordnungssystem Determinismus zu erreichen.
Kurze Beschreibung der Figuren
1 ist ein logisches Blockdiagramm eines dynamischen Speicherzuordnungssystems, in welchem die vorliegende Erfindung implementiert werden kann.
2 ist ein Flußdiagramm, welches die Arbeitsweise der „DoPreallocated-Methode" des Strangobjekts gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
3 ist ein Flußdiagramm, welches die Betriebsweise des Zuordnungsmanagers in Reaktion auf eine Speicherzuordnungsanforderung gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
4 ist ein logisches Blockdiagramm eines mehrsträngigen dynamischen Speicherzuordnungssystems, in welchem die vorliegende Erfindung implementiert sein kann.
5 ist ein Flußdiagramm, welches die Betriebsweise der „DoPreallocated-Methode" des Strangobjekts gemäß einer zweiten Ausführungsform der vorliegenden Erfindung zeigt.
6 ist ein Flußdiagramm, welches die Betriebsweise des Zuordnungsmanagers in Reaktion auf eine Speicherzuordnungsanforderung entsprechend einer zweiten Ausführungsform der vorliegenden Erfindung zeigt.
7 ist ein Hardware-Blockdiagramm eines Computersystems, in welchem die vorliegende Erfindung implementiert sein kann.
Genaue Beschreibung der Ausführungsform(en)
Gemäß 1 ist ein logisches Blockdiagramm eines dynamischen Speicherzuordnungssystems 100 dargestellt, in welchem die vorliegende Erfindung implementiert sein kann. Für Zwecke der Darstellung wird die Erfindung nachstehend unter Bezug auf ein System beschrieben, das auf der Java^TM-Programmier/Ausführumgebung beruht, die von Sun Microsystems, Inc. in Mountain View, Kalifornien entwickelt wurde. Es versteht sich jedoch, daß die vorliegende Erfindung nicht darauf beschränkt ist, sondern stattdessen effektiv auch auf andere Plattformen und Systeme angewendet werden kann.
Wie in 1 dargestellt, weist das System 100 einen Speicherhaufen 102 für die Aufnahme dynamischer Speicherzuordnungen während einer Programmausführung auf. Der Speicherhaufen 102 repräsentiert den gesamten dynamischen Speicherraum, der für die Verwendung durch Programmausführungseinheiten, wie zum Beispiel Objekte, global verfügbar ist. Der Speicherhaufen 102 kann Teile 104 haben, die besetzt sind (d.h. Teile, die aktuell durch Objekte verwendet werden) und Teile 106, die frei und für die Zuordnung neuer Objekte verfügbar sind. Wenn neue Objekte während der Programmausführung instantiiert werden, wird Speicherraum den freien Bereichen bzw. Abschnitten 106 des Haufens 102 zugeordnet. Wenn alte Objekte überflüssig werden, werden ihre zugehörigen besetzten Speicherräume 104 an den Haufen 102 für die erneute Verwendung durch künftige neue Objekte freigegeben. Auf diese Weise wird der Speicher in dem Haufen 102 verwendet und wiederverwendet, um sich einer dynamischen Speicherzuordnung anzupassen. Zusätzlich zu den freien 106 und besetzten 104 Bereichen kann der Speicherhaufen 102 weiterhin einen oder mehrere vorab zugeordnete Speicherräume 108 haben. Wie weiter unten noch erläutert wird, kann dieser vorab zugeordnete Speicherraum 108 verwendet werden, um gemäß der vorliegenden Erfindung deterministische Speicherzuordnungen zu erzielen.
Die Verwaltung des Haufens 102 wird durch den Speicherzuordnungs-/Ausführungsmanager 110 durchgeführt. Insbesondere steuert der Manager 110 die Zuordnung von Speicher aus dem Haufen 102 und die Rückgabe von Speicher zurück in den Haufen 102. In einer Ausführungsform wird die Rückgabe von Speicher zurück zu dem Haufen 102 mit Hilfe eines GC-Vorgangs durchgeführt. Zusätzlich zu der Steuerung des Haufens 102 verwaltet der Manager 110 auch den Gesamtbetrieb und den Ausführungsstrom des Systems 100. In einer Ausführungsform nimmt der Manager 110 die Form einer virtuellen Java^TM-Maschine (Java^TM VM) an, wie diejenige, die beispielsweise in der Beschreibung The Java^TM Virtual Machine Specification, Second Edition, von Tim Lindholm und Frank Yellin, Addison-Wesley, 1999, beschrieben wird, die hier durch diese Bezugnahme aufgenommen wird.
Für Zwecke der Verwaltung des Haufens 102 weist der Manager 110 zumindest zwei Funktionen auf, die aufgerufen werden können, um Speicherzuordnungen durchzuführen: (1) eine „normale" Zuordnungsfunktion; und (2) eine „vorab zugeordnete" Zuordnungsfunktion. Unter der normalen Funktion wird Speicher für neue Objekte aus dem freien Raum 106 auf den Haufen 102 zugeordnet bzw. zugewiesen. Dies ist eine typische Speicherzuordnung und sie kann, wie bei typischen Zuordnungen, einen GC-Vorgang auslösen, wenn der freie Raum auf bzw. in dem Haufen unterhalb eines gewissen Schwellwertes liegt. Mit der Vorabzuordnungsfunktion wird andererseits Speicher nicht aus dem freien Raum 106 des Haufens 102 zugeordnet, sondern statt dessen aus dem vorab zugeordneten Speicherraum 108. Da diese Art der Zuordnung mit Speicherraum 108 durchgeführt wird, der bereits zugeordnet worden ist, ist sichergestellt, daß dies keinen GC-Vorgang auslöst. Wie unten noch genauer beschrieben wird, wird die Vorabzuordnungsfunktion in der vorliegenden Erfindung verwendet, um eine deterministische Speicherzuordnungsantwort bzw. -reaktion zu erzielen.
Das System 100 weist weiterhin ein Objekt PreallocationContext 112 auf. Dieses Objekt stellt ein Mittel für den Aufruf von einem oder mehreren der vorab zugeordneten Speicherräume 108 auf dem Haufen bereit. In einer Ausführungsform bewirkt der Konstrukteur des Objekts 102, wenn das Objekt PreallocationContext 112 instantiiert wird, daß ein zusammenhängender Satz von Speicherraum 108, welcher eine Größe N hat (die Größe N wird spezifiziert zu dem Zeitpunkt, zu welchem das Objekt 112 instantiiert wird), auf bzw. in dem Haufen zugeordnet wird. Sobald dieser Speicherraum 108 vorab zugeordnet worden ist, kann er verwendet werden, um nachfolgende Speicherzuordnungen auszuführen, die mit Sicherheit keine GC-Vorgänge auslösen. An dieser Stelle sei angemerkt, daß der Vorgang des Zuordnens des vorab zugeordneten Speicherraums 108 einen GC-Vorgang auslösen kann, wenn der freie Raum 106 in dem Haufen 102 unterhalb eines gewissen Schwellwertniveaus liegt. Wenn jedoch der vorab zugeordnete Speicherraum 108 einmal zugeord net worden ist, so lösen alle nachfolgenden Zuordnungen innerhalb des vorab zugeordneten Speicherraums 108 garantiert keinen GC-Vorgang aus.
Was die Attribute angeht, so weist das Objekt PreallocationContext 112 einen Startzeiger, einen aktuellen Zeiger und einen Endzeiger auf. Der Startzeiger weist auf den Beginn 120 des vorab zugeordneten Speicherraums 108, welcher zu dem Objekt 112 gehört. Der Endzeiger zeigt auf das Ende 124 des vorab zugeordneten Speicherraums 108 und der aktuelle Zeiger zeigt auf die Stelle 122, an welcher Speicher zugeordnet worden ist. Der Speicherraum zwischen dem Startzeiger und dem aktuellen Zeiger repräsentiert den Speicherraum, der Objekten zugeordnet worden ist. der Speicherraum zwischen dem Endzeiger und dem aktuellen Zeiger repräsentiert den freien Speicherraum, der verwendet werden kann, um künftige Speicherzuordnungsanforderungen zu erfüllen. Wenn das Objekt 112 zunächst instantiiert wird, weisen der Startzeiger und der aktuelle Zeiger auf dieselbe Position 120, da noch keine Zuordnungen durchgeführt worden sind.
Das System 100 weist weiterhin ein Thread-Objekt 114 auf, das eine Abstraktion eines aktuellen Strangs (bzw. Fadens) der Ausführung repräsentiert. Wenn ein Thread-Objekt 114 instantiiert wird und seine Startmethode aufgerufen wird, so wird dem Thread-Objekt 114 ein aktueller Strang der Ausführung zugeordnet, und das Thread-Objekt 114 wird danach verwendet, um die gesamte Context-Information, die zu diesem Strang der Ausführung gehört, aufzubewahren. Das Thread-Objekt 114 hat eine Mehrzahl von damit verknüpften Methoden und Attributen. Diese umfassen ein Attribut AllocFunction und eine Methode DePreallocated.
Das Attribut AllocFunction gibt an, welche Speicherzuordnungsfunktion des Speicherzuordnungsmanagers 110 verwendet werden soll, wenn Speicherzuordnungen für diesen Strang der Ausführung durchgeführt werden. Wenn das Attribut AllocFunction auf „normal" gesetzt wird, so verwendet der Manager 110 die normale Funktion, um Speicher für diesen Strang zuzuordnen. Wenn das Attribut AllocFunction auf „vorab zugeordnet" gesetzt ist, so verwendet der Manager 110 die vorab zugewiesene Funktion, um Speicherraum für diesen Strang zuzuordnen.
Die Methode DoPreallocated wird aufgerufen, wenn es erforderlich ist, in einer nachfolgenden Aktion ein deterministisches Speicherzuordnungsverhalten zu erzielen. Genauer gesagt garantiert die Methode DoPreallocated, daß alle Speicherzuordnungen, die in Verbindung mit der nachfolgenden Aktion durchgeführt werden, ohne Auslösen eines GC-Vorgangs und ohne an Fragmentierungseffekten zu leiden durchgeführt werden. Demnach werden die Zuordnungen in im wesentlichen konstanter Zeit ausgeführt. In einer Ausführungsform ist die Methode DoPreallocated eine statische Methode (was bedeutet, daß sie an die Thread-Objekt-Klasse gebunden ist, im Gegensatz zu einer spezifischen Thread-Objekt-Instanz), und sie nimmt zwei Parameter auf: (1) einen Größenparameter, und (2) einen Aktionsparameter. Der Größenparameter gibt die Größe des vorab zugeordneten Speicherraums 108 an, der zugeordnet werden sollte, wenn das Objekt PreallocationContext 112 instantiiert wird. der Aktionsparameter liefert einen Eintrittspunkt zu einem Codesatz, der ausgeführt werden soll. Die Methode DoPreallocate stellt sicher, daß, während dieser Codesatz ausgeführt wird, alle Speicherzuordnungen aus dem vorab zugeordneten Speicherraum 108 vorgenommen werden. Wenn alle Speicherzuordnungen aus dem vorab zugeordneten Speicherraum 108 vorge nommen wurden, so werden keine GC-Vorgänge aufgerufen und man spürt keine Fragmentierungseffekte. Dementsprechend erzielt man bei dem Speicherzuordnungsvorgang eine Zuordnung mit im wesentlichen konstanter Zeitdauer und damit einen Determinismus.
Gemäß dem Systemdiagramm nach 1 und den Flußdiagrammen nach den 2 und 3 wird nunmehr die Arbeitsweise einer Ausführungsform der vorliegenden Erfindung beschrieben. Zu Beginn sei angenommen, daß das Thread-Objekt 114 instantiiert worden ist und daß seine Startmethode aufgerufen worden ist, so daß dem Objekt 114 ein Ausführungs-Thread bzw. -Strang zugeordnet worden ist. Es sei weiterhin angenommen, daß der Ausführungsstrang einen Satz von Code ausgeführt hat und daß während einer solchen Ausführung der Strang auf den Aufruf einer Methode DoPreallocated trifft, die entlang eines Größenparameters N eines Aktionsparameters AC verläuft. Dies bewirkt, daß die Methode DoPreallocated der Objektklasse Thread aufgerufen wird. Wenn die Methode DoPreallocated aufgerufen ist, stellt sie fest (204, 2), welcher Strang sie aufgerufen hat. In diesem besonderen Beispiel ist es der Strang, der zu dem Thread-Objekt 114 gehört. Wenn diese Feststellung getroffen worden ist, instantiiert (208) die Methode DoPreallocated das Objekt 112 PreallocationContext, welches entlang N als Größenparameter verläuft. Der Konstrukteur des Objekts 112 PreallocationContext veranlaßt während der Instantiierung, daß ein vorab zugeordneter Speicherraum 108 der Größe N auf bzw. von dem Haufen 102 zugeordnet wird. Die Startzeiger und aktuellen Zeiger werden so eingestellt, daß sie auf den Beginn 120 des vorab zugeordneten Speicherraums 108 zeigen, und der Endzeiger wird so eingestellt, daß er auf das Ende 124 des vorab zugeordneten Speicherraums 108 zeigt. Der vorab zugeordnete Speicherraum 108 ist nun für die Benutzung bereit.
Zusätzlich zum Instantiieren des Objekts 112 PreallocationContext stellt (212) die Methode DoPreallocated auch das Attribut AllocFunction des Thread-Objekts 114 auf „preallocated" (vorab zugeordnet). Dies bewirkt, daß der Zuordnungsmanager 110 alle nachfolgenden Speicherzuordnungen für diesen Strang unter Verwendung der Zuordnungsfunktion der Vorabzuordnung verwendet. Wenn das Attribut AllocFunktion gesetzt ist, bewirkt die Methode DoPreallocated, daß der durch den Aktionsparameter AC aufgerufene Code ausgeführt wird (216). Während dieser Code ausgeführt wird, müssen mit hoher Wahrscheinlichkeit eine oder mehrere Speicherzuordnungen ausgeführt werden. Jedesmal, wenn eine Speicherzuordnung erforderlich ist, wird der Zuordnungsmanager 110 aufgerufen. Wenn der Manager 110 aufgerufen ist, so empfängt er (304, 3) die Speicherzuordnungsanforderung. Er überprüft dann (308) den Wert des Attributs AllocFunction des Strangs, der die Zuordnungsaufforderung gemacht hat. Wenn AllocFunction auf „normal" gesetzt ist, so wird diese normale Zuordnungsfunktion verwendet, um die Speicherzuordnung durchzuführen (312), wo bei in diesem Fall die Zuordnung aus dem freien Raum 106 des Haufens 102 vorgenommen wird. Da dieses eine normale Zuordnung ist, kann sie einen GC-Vorgang auslösen. Wenn andererseits das Attribut AllocFunction auf „preallocated" eingestellt ist (wie es im vorliegenden Beispiel der Fall ist), so verwendet der Zuordnungsmanager 110 die Funktion „vorab zugeordnet", um die Speicherzuordnung durchzuführen. Unter der Funktion „vorab zugeordnet" ordnet der Speicher 110 keinen Speicher aus dem freien Raum 106, sondern statt dessen aus dem vorab zugeordneten Speicher raum 108 zu. Im Ergebnis ist sichergestellt, daß die Speicherzuordnung keinen GC-Vorgang auslöst und frei ist von Fragmentierungseffekten. Indem diese beiden Ursachen der Unvorhersagbarkeit beseitigt werden, ist es möglich, in dem Speicherzuordnungsvorgang ein deterministisches Verhalten zu erzielen.
In einer Ausführungsform wird die Speicherzuordnung gemäß der Funktion Preallocated folgendermaßen durchgeführt. Zu Beginn wird die Feststellung getroffen (316), ob in dem vorab zugeordneten Speicherraum 108 genügend Platz vorhanden ist, um die Speicherzuordnungsanforderung zu erfüllen. Dies kann geschehen durch Vergleichen der Menge an freiem Raum (des Raumes zwischen dem aktuellen Zeiger 122 und dem Endzeiger 124) in dem vorab zugeordneten Speicherraum 108 mit der Menge an angefordertem Speicherraum. Wenn es nicht genug freien Speicherraum gibt, um die Anforderung zu erfüllen, so wird ein Fehler „Speicherüberlauf" („out of memory") erzeugt (324). Es wird kein GC-Vorgang aufgerufen. Wenn andererseits genügend Speicherraum in dem vorab zugeordneten Speicherraum 108 vorhanden ist, um die Anforderung zu erfüllen, so wird die Speicherzuordnung durchgeführt (320), wobei der vorab zugeordnete Speicherraum verwendet wird. In einer Ausführungsform wird Speicher aus dem Raum 108 zugeordnet, indem der aktuelle Zeiger des Objekts PreallocationContext um den Betrag des zum Erfüllen der Speicheranforderung verwendeten Raums weitergesetzt wird. Die Speicherzuordnung unter Verwendung eines vorab zugeordneten Speicherraums 108 wird auf diese Weise durchgeführt.
Wieder gemäß 2 wird der Satz von Code, der durch den Aktionsparameter AC aufgerufen wird, weiter ausgeführt, bis die Ausführung abgeschlossen ist. An diesem Punkt erfolgt die Rückkehr zu der Methode DoPreallocated. Nach der Rückkehr gibt die Methode DoPreallocated ihren Teil bzw. Besitz an dem vorab zugeordneten Speicherraum 108 frei (220). Zusätzlich setzt sie das Attribut AllocFunction des Thread-Objekts 114 zurück (224) auf „normal", so daß alle nachfolgenden Speicherzuordnungen, die für diesen Strang vorgenommen werden, normale Zuordnungen sind. Wenn das Attribut AllocFunction auf normal gesetzt ist, kehrt die Methode DoPreallocated zu dem Code, welcher sie aufgerufen hat, zurück. Damit ist die Methode DoPreallocated abgeschlossen.
An diesem Punkt erkennt man, daß die vorliegende Erfindung einen minimalen Einfluß auf den GC-Prozeß hat. Wenn Speicherraum in dem vorab zugeordneten Speicherraum 108 einem Objekt zugeordnet wird, so ist dieser Speicherraum dem regulären GC-Vorgang ausgesetzt. Selbst wenn also der vorab zugeordnete Speicherraum 108 von dem Startzeiger bis zum Endzeiger reicht, kann der Speicherraum zwischen dem aktuellen Zeiger und dem Startzeiger (welcher den Speicherraum repräsentiert, der Objekten zugeordnet worden ist) eine „Abfallsammlung" (Aufsammlung von nicht mehr benötigtem Speicherraum) erfahren. Dies ist ein sehr vorteilhaftes Ergebnis, da es bedeutet, daß die vorliegende Erfindung keinen speziellen Mechanismus zur Aufhebung von Speicherzuordnung benötigt, um die Zuordnung von Speicher aus dem vorab zugeordneten Speicherraum 108 aufzuheben. Statt dessen kann der reguläre GC-Mechanismus verwendet werden. Im Ergebnis erreicht die vorliegende Erfindung ein deterministisches Verhalten mit einem minimalen zusätzlichen Aufwand.
Insoweit ist die Erfindung im Kontext eines Systems mit einem einzelnen Strang beschrieben worden. Es versteht sich jedoch, daß mit gewissen Ergänzungen die vorliegende Erfindung auch auf mehrsträngige Systeme ausgedehnt werden kann. 4 zeigt ein logisches Blockdiagramm eines mehrsträngigen Systems 400, in welchem die vorliegende Erfindung implementiert werden kann.
Das System 400 weist zunächst einen Speicherhaufen 402 auf, welcher den gesamten dynamischen Speicherraum repräsentiert, der für die Aufnahme dynamischer Speicherzuordnungen verfügbar ist. Wie bei dem Haufen 102 nach 1 weist auch der Haufen 402 besetzten Speicherraum 404, freien Speicherraum 406 und vorab zugeordneten Speicherraum 408 auf. Man beachte jedoch, daß die vorab zugeordneten Speicherbereiche 408 in 4 als „Pools" und nicht als „Räume" bzw. „Spaces" bezeichnet werden. Dieser Unterschied in der Begriffswahl soll die Tatsache verdeutlichen, daß die Speicherpools 408 in dem Haufen 402 durch mehrere Stränge gemeinsam verwendet werden können. Das gemeinsame Verwenden vorab zugeordneter Speicherpools 408 wird in einem späteren Abschnitt genauer beschrieben.
Das System 400 weist weiterhin einen Speicherzuordnungs-/Ausführungsmanager 410 für die Verwaltung des Speicherhaufens 402 und den Gesamtstrom der Ausführung des Systems 400 auf. Der Manager 410 ist in vieler Hinsicht dem Manager 110 nach 1 ähnlich. Der Manager 410 weist jedoch die zusätzliche Fähigkeit für das Verwalten mehrerer Ausführungsstränge auf. Zusätzlich wird die Vorabzuordnungsfunktion des Managers 410 in der Weise verstärkt oder ergänzt, daß er mit der zusätzlichen Fähigkeit versehen ist, die zusätzliche Komplexität zu handhaben, die mit der gemeinsamen Verwendung eines vorab zugeordneten Speicherpools 408 durch mehrere Stränge zusammenhängt. Genauer gesagt kann es, da mehrere Stränge denselben Pool 408 gemeinsam verwenden, Zeiten geben, zu welchen mehrere Stränge gleichzeitig Speicherzuordnungen von demselben vorab zugeordneten Pool 408 anfordern. Um diese Möglichkeit zu bewältigen, weist die Vorabzuordnungsfunktion des Managers 410 die Fähigkeit auf, einen wechselseitigen Ausschlußvorgang für die mehrfachen Anforderungen durchzuführen. Der wechselseitige Ausschluß stellt sicher, daß eine Speicherzuordnung auf einem vorab zugeordneten Pool 408 zu einer gegebenen Zeit nur für einen Strang durchgeführt wird. Für Zwecke der vorliegenden Erfindung kann der Vorgang des wechselseitigen Ausschlusses irgendeine bekannte Verfahrensweise für das wechselseitige Ausschließen implementieren, was Verriegelungen bzw. Zwischenspeicher, Priorität und Vermittlung einschließt, ohne hierauf beschränkt zu sein. Die Vorabzuordnungsfunktion des Managers 410 wird in einem späteren Abschnitt genauer beschrieben. In einer Ausführungsform hat der Manager 410 die Form einer virtuellen Java^TM-Maschine.
Das System 400 weist weiterhin ein Objekt 412 PreallocationContext auf. Das Objekt 412 ist dem Objekt 112 PreallocationContext gemäß 1 ähnlich insofern, als es einen Konstrukteur und drei Zeigerattribute (Start, aktuell und Ende) aufweist. Zusätzlich weist das Objekt aber auch eine Methode Available (verfügbar) und eine Methode Replenish (auffüllen) auf. Wenn die Methode Available aufgerufen ist, so liefert sie einen Wert, der den Betrag an Speicherraum anzeigt, der in einem aktuell vorab zugeordneten Speicherpool 408, der dem Objekt 412 PreallocationContext zugeordnet ist, verblieben ist. Diese Methode kann beispielsweise aufgerufen werden, um festzustellen, wann der vorab zugeordnete Speicherpool 408 aufgefüllt werden muß.
Wenn es erforderlich wird, den Pool 408 aufzufüllen, kann die Methode Replenish aufgerufen werden. Wenn diese Methode aufgerufen ist, bewirkt sie, daß ein weiterer vorab zugeordneter Speicherpool zugeordnet wird. Man beachte, daß die Methode Replenish nicht bewirkt, daß der existierende vorab zugeordnete Speicherpool freigegeben oder seine Zuordnung aufgehoben wird, sie bewirkt einfach, daß ein weiterer Pool vorab zugeordnet wird. Um dieses zu veranschaulichen sei angenommen, daß der vorab zugeordnete Speicherpool 408a der Speicherpool ist, der aktuell dem Objekt 412 zugeordnet ist. Es sei weiter angenommen, daß der Speicherraum in dem Pool 408 fast vollständig verbraucht ist, so daß die Methode Replenish aufgerufen wird. Wenn die Methode Replenish aufgerufen ist, so bewirkt sie, daß ein weiterer Speicherpool 408b, welcher dieselbe Größe wie der Pool 408a hat, vorab zugeordnet wird. Wenn der neue Pool 408b zugeordnet ist, werden die Zeiger für Start, aktuell und Ende so eingestellt, daß sie auf den neuen aktuellen Pool 408b weisen. Wenn das geschehen ist, ist der neue Pool 408b für den Gebrauch bereit. Für Stränge, die mit dem Objekt 412 PreallocationContext zusammenwirken, erscheint es, als sei der vorab zugeordnete Speicherpool gelöscht worden und für die erneute Verwendung verfügbar gemacht worden. Tatsächlich wurde jedoch keinerlei Löschen, Aufhebung einer Zuordnung, Abfallsammlung oder Speicherfreigabevorgang durchgeführt. Es wurde einfach ein neuer Pool 408b erzeugt. Wie diese Diskussion zeigt, ist es in der vorliegenden Erfindung möglich, daß mehrere vorab zugeordnete Speicherpools 408a, 408b demselben Objekt 412 PreallocationContext zugeordnet werden. Wie zuvor in Verbindung mit dem System nach 1 erwähnt, wird, wenn Speicherraum innerhalb eines vorab zugeordneten Speicherpools einem Objekt zugeordnet worden ist, dieser Speicherraum reguläten GC-Vorgängen ausgesetzt. Deshalb wird schließlich für den gesamten zugeordneten Speicherraum in den Speicherpools 408a, 408b eine „Abfallsammlung" durchgeführt und er wird an den Haufen 402 zurückgegeben. Was jedoch nicht der Abfallsammlung ausgesetzt wird, ist der Speicherraum in jedem Pool 408a, 408b, der keinen Objekten zugeordnet worden war. Es ist Sache der Methode DoPreallocated der Strangobjekte 414a, 414b, diese Speicherräume freizugeben, wie unten noch erläutert wird.
Das Auffüllen der vorab zugeordneten Speicherpools 408 wird durch den Kontextmanager 416 gesteuert bzw. kontrolliert. In einer Ausführungsform läuft der Kontextmanager 416 auf seinem eigenen getrennten Strang bzw. Thread (Faden) ab und ist dafür ausgelegt, in regelmäßigen Intervallen aufzuwachen bzw. aktiviert zu werden, um eine Instandhaltung der Speicherpools 408 durchzuführen. Wenn er erwacht bzw. aktiv wird, stellt der Kontextmanager 416 fest (indem er die Methode Available des Objekts PreallocationContext aufruft), ob der verfügbare Speicherraum in dem aktuell vorab zugeordneten Speicherpool, der zu dem Objekt 412 gehört, unter einen gewissen Schwellwert abgesunken ist. Wenn nicht, so wird nichts weiter unternommen. Wenn andererseits der verfügbare Speicherraum unter den Schwellwert abgesunken ist, so ruft der Kontextmanager 416 die Methode Replenish des Objekts 412 auf, um zu bewirken, daß ein neuer Speicherpool vorab zugeordnet wird. Auf diese Weise verhindert der Kontextmanager 416, daß dem Objekt 412 PreallocationContext der vorab zugeordnete Speicherraum ausgeht.
Das System 400 weist weiterhin eine Mehrzahl von Thread-Objekten („Strangobjekten") 414a, 414b auf, die jeweils eine Abstraktion eines aktuellen Ausführungsstrangs repräsentieren. In 4 sind aus Gründen der Einfachheit nur zwei Thread-Objekte dargestellt, es versteht sich jedoch, daß irgendeine beliebige Anzahl von Strängen in dem System 400 aufgenommen werden kann. Die Thread-Objekte 414a, 414b sind dem Thread-Objekt 114 nach 1 weitgehend ähnlich. Es gibt jedoch einen Unterschied in der Methode DoPreallocated der Objekte 414a, 414b, der erwähnenswert ist. Anstatt einen Größenparameter als eines der Argumente aufzunehmen, nimmt die Methode DoPreallocated der Objekte 414a, 414b einen speziellen Objektaufruf PreallocationContext auf. Indem ein spezieller Objektaufruf PreallocationContext als Argument aufgenommen wird, macht die Methode DoPreallocated der Objekte 414a, 414b es möglich, daß unterschiedliche Methodenaufrufe DoPreallocated von unterschiedlichen Strängen auf dasselbe Objekte PreallocationContext zurückgreifen können. Zusätzlich zur Aufnahme eines unterschiedlichen Arguments ist die Implementierung der Methode DoPreallocated der Objekte 414a, 414b ebenfalls unterschiedlich. Dieser Unterschied wird deutlich in der folgenden Erläuterung.
Gemäß dem Systemdiagramm nach 4 und den Flußdiagrammen 5 und 6 wird nun die Betriebsweise des mehrsträngigen Systems 400 beschrieben. Zu Beginn sei angenommen, daß die Thread-Objekte 414a, 414b instantiiert worden sind und daß ihre Startmethoden aufgerufen wurden, so daß sie aktuellen Ausführungssträngen zugeordnet worden sind. Es sei weiterhin angenommen, daß diese Ausführungsstränge Sätze von Code ausgeführt haben und daß während einer solchen Ausführung einer der Stränge das Objekt 412 PreallocationContext instantiiert. Während der Instantiierung bewirkt der Konstrukteur des Objekts 414 PreallocationContext, daß ein vorab zugeordneter Speicherpool 408a, der eine gewisse Größe N hat, auf dem Haufen 4102 zugeordnet wird. Der Startzeiger und der aktuelle Zeiger werden so eingestellt, daß sie auf den Beginn 420 des vorab zugeordneten Speicherraums 408a zeigen, und der Endzeiger wird so eingestellt, daß er auf das Ende 424 des vorab zugeordneten Speicherraums 4078a zeigt. Der vorab zugeordnete Speicherraum 408a ist nunmehr für den Gebrauch bereit.
Es sei nun angenommen, daß bei dem Prozeß des Ausführens von Code einer der Stränge auf einen Methodenaufruf DoPreallocated stößt, der entlang eines Parameters PC PreallocationContext verläuft, der auf das Objekt 412 Bezug nimmt, sowie entlang eines Aktionsparameters AC. Dies bewirkt, daß die Methode DoPreallocated der Klasse Thread-Objekt aufgerufen wird. Wenn die Methode DoPreallocated aufgerufen worden ist, so stellt sie fest (504, 5), welcher Strang sie aufgerufen hat. In diesem besonderen Beispiel sei angenommen, daß es der Strang ist, der zu dem Thread-Objekt 414a gehört. Wenn dies festgestellt worden ist, stellt die Methode DoPreallocated (560) das Attribut AllocFunction des Thread-Objekts 414a auf „vorab zugeordnet". Dies bewirkt, daß der Zuordnungsmanager 410 alle nachfolgenden Speicherzuordnungen für diesen Strang unter Verwendung der Zuordnungsfunktion „preallocated" bzw. „vorab zugeordnet" ausführt. Wenn das Attribut AllocFunction gesetzt ist, bewirkt die Methode DoPreallocated, daß der durch den Aktions parameter AC aufgerufene Code ausgeführt wird (520). Während dieser Code ausgeführt wird, werden sehr wahrscheinlich eine oder mehrere Speicherzuordnungen durchgeführt. Jedesmal, wenn eine Speicherzuordnung erforderlich ist, wird der Zuordnungsmanager 410 aufgerufen.
Wenn der Manager 410 aufgerufen wird, empfängt er 8604, (6) die Speicherzuordnungsanforderung. Er stellt dann fest (608), welcher Strang die Zuordnungsanforderung abgegeben hat und erhält den Wert für AllocFunction für diesen Strang (612). Wenn dies geschehen ist, überprüft (620) der Manager 410 das Attribut AllocFunction dieses Strangs. Wenn AllocFunction auf „normal" gesetzt ist, so wird die normale Zuordnungsfunktion verwendet, um die Speicherzuordnung durchzuführen, wobei in diesem Fall die Zuordnung von dem freien Raum 106 des Haufens 402 vorgenommen wird (624). Da dieses eine normale Zuordnung ist, kann sie einen GC-Vorgang auslösen. Wenn andererseits das Attribut AllocFunction auf „vorab zugeordnet" eingestellt ist (wie es in diesem Beispiel der Fall ist), so verwendet der Zuordnungsmanager 410 die Funktion „vorab zugeordnet" bzw. „preallocated", um die Speicherzuordnung durchzuführen. Unter der Funktion preallocated ordnet der Manager 410 keinen Speicher aus dem freien Raum 406 zu, sondern statt dessen aus dem vorab zugeordneten Speicherpool 408, der zu dem PreallocationContext gehört, der in dem Methodenaufruf DoPreallocated angegeben ist. Im Ergebnis ist sichergestellt, daß die Speicherzuordnung keinen GC-Vorgang auslöst und frei von Fragmentierungseffekten ist.
Entsprechend der Funktion Preallocated führt der Manager 410, bevor Speicher aus dem vorab zugeordneten Speicherpool 408a zugeordnet wird, zunächst einen wechselseitigen Ausschlußvorgang (626) aus, falls dies notwendig ist. Wie zuvor bereits erwähnt, ist es in einem mehrsträngigen System möglich, daß mehrere Stränge gleichzeitig eine Speicherzuordnung von demselben PreallocationContext anfordern. Wenn dies geschieht, muß der Manager 410 einen wechselseitigen Ausschlußvorgang mit den mehreren Anforderungen durchführen, um sicherzustellen, daß jeweils nur eine Anforderung durchgeführt wird. An diesem Punkt sollte erwähnt werden, daß, falls ein wechselseitiger Ausschlußvorgang durchgeführt worden ist, die Zeit für die Speicherzuordnung variieren kann. Trotz dieser Varianz ist jedoch das Verhalten der Zuordnungszeit noch immer deterministisch. Um dies näher auszuführen sei angenommen, daß fünf Stränge gleichzeitig eine Speicherzuordnung von demselben PreallocationContext anfordern. Üblicherweise erfordert ein Speicherzuordnungsvorgang einen Zeitbetrag X. Wegen der Konkurrenz müssen jedoch einige dieser Stränge warten und damit ist die Speicherzuordnungszeit länger. Da jedoch die vorliegende Erfindung sicherstellt, daß, wenn ein Strang Zugang zu dem PreallocationContext erhält, der jeweilige Speicherzuordnungsvorgang einen konstanten Betrag X an Zeit erfordert, so ist klar, daß im schlimmsten Fall die Speicherzuordnungszeit für irgend einen der fünf Stränge 5X betragen kann. Demnach ist, selbst wenn das Warten dazu führen kann, daß die Zuordnungszeiten variieren, das Verhalten des Speicherzuordnungsmechanismus immer noch deterministisch und vorhersagbar. Es ist dieser Determinismus, der üblicherweise in Systemen wie zum Beispiel Echtzeitsystemen, erforderlich ist.
Wenn der wechselseitige Ausschlußvorgang (falls notwendig) ausgeführt worden ist, kann Speicher von dem vorab zugeordneten Speicherpool 408a zugeordnet werden. In einer Ausfüh rungsform wird die Speicherzuordnung folgendermaßen durchgeführt. Zu Beginn wird festgestellt (628), ob genügend Speicherraum in dem vorab zugeordneten Speicherpool 408a vorhanden ist, um die Speicherzuordnungsanforderung zu erfüllen. Dies kann geschehen durch Vergleichen des Betrags an Freiraum in dem vorab zugeordneten Speicherpool 408a, der dem PreallocationContext 412 zugeordnet ist (was man durch Aufrufen der Methode Available erhält) mit dem Betrag an angefordertem Speicherraum. Wenn nicht genügend freier Speicherraum vorhandnen ist, um die Anforderung zu erfüllen, so wird ein „Speicherüberlauf"-Fehler erzeugt (636). Es wird kein GC-Vorgang aufgerufen. Wenn andererseits genügend Speicherraum in dem vorab zugeordneten Speicherpool 408a vorhanden ist, um die Anforderung zu erfüllen, so wird die Speicherzuordnung unter Verwendung des vorab zugeordneten Speicherpools ausgeführt. In einer Ausführungsform wird Speicher aus dem Pool 408a zugeordnet, indem der aktuelle Zeiger des Objekts PreallocationContext um den Betrag des Raums weitergesetzt wird, der gebraucht wird, um die Speicheranforderung zu erfüllen.
Die Speicherzuordnung unter Verwendung eines vorab zugeordneten Speicherpools 408a, der zu einem spezifischen PreallocationContext 412 gehört, ist damit durchgeführt.
Wiederum gemäß 5 wird der Satz des Codes, der durch den Aktionsparameter AC aufgerufen wurde, weiterhin ausgeführt, bis die Ausführung abgeschlossen ist. An diesem Punkt erfolgt eine Rückkehr zu der Methode DoPreallocated. Nach der Rückkehr stellt die Methode DoPreallocated fest (524), ob irgendeiner der anderen Stränge aktuell den Speicherpool 408a verwendet, von welchem die Methode DoPreallocated ausgeht. In einer Ausführungsform wird, damit die Methode DoPreallocated diese Feststellung treffen kann, eine Referenz- bzw. Aufrufzahl durch das Objekt 412 PreallocationContext für jeden der Vorabzuordnungsspeicherpools 408a, 408b bereitgehalten, die zu dem Objekt 412 gehören. Wann immer ein Thread bzw. Strang in einen Pool 408a, 408b eintritt, wird die zu diesem Pool gehörige Referenzzahl heraufgesetzt. Wann immer ein Thread bzw. Strang einen Pool 408a, 408b verläßt, wird die Referenzzahl, die zu diesem Pool gehört, herabgesetzt. Demnach kann die Methode DoPreallocated, indem sie feststellt, ob die Referenzzahl, die zu einem Pool 408a, 408b gehört, den Wert null erreicht hat, feststellen, ob irgendwelche anderen Stränge den Pool aktuell verwenden.
Wenn keine anderen Stränge den Pool 408a verwenden, aus welchem die Methode DoPreallocated heraustritt, so wird der Besitz bzw. Zugriff auf den Pool 408a freigegeben (528). Danach setzt (532) die Methode DoPreallocated das Attribut AllocFunction des Thread-Objekts 414a zurück auf „normal", so daß alle nachfolgenden Speicherzuordnungen, die für diesen Strang vorgenommen werden, normale Zuordnungen sind. Wenn das Attribut AllocFunction auf normal zurückgesetzt ist, kehrt die Methode DoPreallocated zu dem Code zurück, der sie aufgerufen hat. Die Methode DoPreallocated ist dann abgeschlossen.
Übersicht über die Hardware
7 ist ein Blockdiagramm, welches ein Computersystem 700 veranschaulicht, in welchem eine Ausführungsform der Erfindung implementiert werden kann. Das Computersystem 700 enthält einen Bus 702 oder einen anderen Kommunikationsmechanismus für das Kommunizieren von Information, sowie einen Prozessor 704, der mit dem Bus 702 für die Verarbeitung von Information verbunden ist. Das Computersystem 700 enthält auch einen Hauptspeicher 706, wie zum Beispiel einen Speicher mit wahlfreiem Zugriff (RAM) oder eine andere dynamische Speichereinrichtung, die mit dem Bus 702 verbunden ist, um Information und Befehle, die durch den Prozessor 704 ausgeführt werden sollen, zu speichern. Zusätzlich zu der Verwendung zum Implementieren der Haufen 102, 402 kann der Hauptspeicher 706 weiterhin verwendet werden, um temporäre Variable oder andere Zwischeninformationen während der Ausführung von Befehlen zu speichern, die durch den Prozessor 704 ausgeführt werden. Das Computersystem 700 enthält weiterhin einen Nur-Lese-Speicher (ROM) 708, oder eine andere statische Speichereinrichtung, die mit dem Bus 702 verbunden ist, um statische Information und Befehle für den Prozessor 704 zu speichern. Eine Speichereinrichtung 710, wie zum Beispiel eine magnetische Festplatte oder eine optische Platte, ist vorgesehen und mit dem Bus 702 verbunden, um Information und Befehle zu speichern.
Das Computersystem 700 kann über einen Bus 702 mit einer Anzeige 712 verbunden werden, wie zum Beispiel einer Kathodenstrahlröhre (CRT), um für einen Computerbenutzer Information anzuzeigen. Eine Eingabeeinrichtung 714, einschließlich einer alpha-numerischen und sonstigen Tastatur ist mit dem Bus 702 verbunden für die Kommunikation von Informationen und Befehlsauswahl an bzw. mit dem Prozessor 704. Ein weiterer Typ einer Benutzereingabeeinrichtung ist eine Cursorsteuerung 716, wie zum Beispiel eine Maus, ein Trackball oder Cursorrichtungstasten, um Richtungsinfomtation und Befehlsauswahlen an den Prozessor 704 zu kommunizieren und um eine Cursorbewegung auf der Anzeige 712 zu steuern. Diese Eingabeeinrichtung hat typischerweise zwei Freiheitsgrade entlang zweier Achsen, einer ersten Achse (beispielsweise x) und einer zweiten Achse (beispielsweise y), was es erlaubt, daß die Einrichtung Positionen in einer Ebene angibt.
Gemäß einer Ausführungsform wird die Funktionalität der vorliegenden Erfindung durch ein Computersystem 700 in Reaktion darauf bereitgestellt, daß ein Prozessor 704 eine oder mehrere Sequenzen eines oder mehrerer Befehle ausführt, die in dem Hauptspeicher 706 enthalten sind. Derartige Befehle können von irgendeinem anderen computerlesbaren Medium. wie zum Beispiel einer Speichereinrichtung 710, in den Hauptspeicher 706 gelesen werden. Die Ausführung von Sequenzen von Befehlen, die in dem Hauptspeicher 706 enthalten sind, bewirkt, daß der Prozessor 704 die darin beschriebenen Prozeßschritte durchführt. In alternativen Ausführungsformen kann eine hartverdrahtete Schaltung anstelle von oder in Kombination mit Softwarebefehlen verwendet werden, um die Erfindung zu implementieren. Ausführungsformen der vorliegenden Erfindung sind demnach nicht auf irgendeine spezielle Kombination von Hardwareschaltung und Software beschränkt.
Der Begriff „computerlesbares Medium", wie er hier verwendet wird, bezieht sich auf irgendein beliebiges Medium, welches an der Bereitstellung von Befehlen für den Prozessor 704 für die Ausführung teilnimmt. Ein solches Medium kann vielfältige Formen annehmen, einschließlich nichtflüchtiger Medien, flüchtiger Medien und Sendemedien, ohne hierauf beschränkt zu sein. Nichtflüchtige Medien umfassen beispielsweise optische oder magnetische Festplatten, wie zum Beispiel eine Speichereinrichtung 710. Flüchtige Medien umfassen einen dynamischen Speicher, wie zum Beispiel den Hauptspeicher 706. Übertragungs- bzw. Sendemedien umfassen Koaxialkabel, Kupferdraht und faseroptische Fasern bzw. Faseroptiken, einschließlich der Drähte oder Kabel, welche den Bus 702 bilden. Übertragungs- bzw. Sendemedien können auch die Form akustischer oder elektromagnetischer Wellen annehmen, wie zum Beispiel derjenigen, die bei Radiowellen-, Infrarot- und optischen Datenkommunikationen erzeugt werden.
Übliche Formen computerlesbarer Medien umfassen beispielsweise eine Wechselplatte, eine flexible Platte, eine Festplatte, Magnetbänder oder irgendein anderes magnetisches Medium, eine CR-ROM, oder irgendein anderes optisches Medium, Steckkarten, Papierband, irgendein anderes physikalisches Medium mit einem Muster von Löchern, einen RAM, einen PRAM, einen EPROM, einen Flash-EPROM, irgendwelche anderen Speicherchips oder Kassetten, eine Trägerwelle, wie sie nachfolgend beschrieben wird oder irgendein anderes Medium, von welchem ein Computer lesen kann.
Beim Ausführen einer oder mehrerer Sequenzen mit einem oder mehreren Befehlen an den Prozessor 704 für die Ausführung können verschiedene Formen computerlesbarer Medien involviert sein. Beispielsweise können die Befehle anfänglich auf einer magnetischen Festplatte eines entfernt gelegenen (anderen) Computers enthalten sein. Der entfernte Computer kann die Befehle in seinen dynamischen Speicher laden und die Befehle über eine Telefonleitung unter Verwendung eines Modems senden. Ein lokales Modem des Computersystems 700 kann die Daten an der Telefonleitung empfangen und einen Infrarotübertrager verwenden, um die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor kann die in dem Infrarotsignal getragenen Daten empfangen und eine geeignete Schaltung kann die Daten auf dem Bus 702 plazieren. Der Bus 702 trägt die Daten an den Hauptspeicher 706, von welchem der Prozessor 704 die Befehle heranholt und ausführt. Die Befehle, die durch den Hauptspeicher 706 empfangen wurden, können optional auf einer Speichereinrichtung 10 entweder vor oder nach der Ausführung durch den Prozessor 704 gespeichert werden.
Das Computersystem 700 enthält auch eine Kommunikationsschnittstelle 718, die mit dem Bus 702 verbunden ist. Die Kommunikationsschnittstelle 718 stellt eine Datenkommunikationsverbindung über zwei Wege mit einer Netzwerkverknüpfung 720 her, die mit einem lokalen Netzwerk 722 verbunden ist. Beispielsweise kann eine Kommunikationsschnittstelle 718 eine ISDN-Karte (Intgegral Services Digital Network-Kartte) oder ein Modem sein, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ von Telefonleitung bereitzustellen. Nach einem anderen Beispiel kann die Kommunikationsschnittstelle 718 eine LAN-Karte (Local Area Network-Karte) sein, um eine Datenkommunikationsverbindung zu einem kompatibelen LAN bereitzustellen. Drahtlose Verbindungen können ebenfalls implementiert sein. In irgendeiner solchen Implementierung sendet und empfängt die Kommunikationsschnittstelle 718 elektrische, elektro-magnetische oder optische Signale, die digitale Datenströme tragen, welche unterschiedliche Informationstypen repräsentieren.
Die Netzwerkverbindung 720 stellt typischerweise eine Datenkommunikation durch ein oder mehrere Netzwerke zu anderen Dateneinrichtungen bereit. Beispielsweise kann die Netzwerkverbindung 720 einen Anschluß durch das lokale Netzwerk 722 zu einem Hostcomputer 724 oder zu einer Datenausrüstung bereitstellen, die durch einen Internet Service Provider (ISP) 726 betrieben wird. Der ISP 726 stellt seinerseits Datenkommunikationsdienste durch das weltweite Paketdatenkommunikationsnetzwerk bereit, welches in üblicher Weise als das „Internet" 728 bezeichnet wird. Lokales Netzwerk 722 und Internet 728 verwenden beide elektrische, elektro-magnetische oder optische Signale, welche digitale Datenströme tragen. Die Signale durch die verschiedene Netzwerke und die Signale auf der Netzwerkverbindung 720 und durch die Kommunikationsschnittstelle 718, welche die digitalen Daten zu und von einem Computersystem 700 tragen, sind beispielhafte Formen von Trägerwellen, welche die Information transportieren.
Das Computersystem 100 kann Nachrichten senden und Daten empfangen, einschließlich Programmcode, und zwar durch ein Netzwerk bzw. Netzwerke, eine Netzwerkverbindung 720 und eine Kommunikationsschnittstelle 718. Bei dem Beispiel des Internets kann ein Server 730 einen angeforderten Code für ein Anwendungsprogramm durch das Internet 728, den ISP 726, das lokale Netzwerk 722 und die Kommunikationsschnittstelle 718 übertragen. Der empfangene Code kann durch den Prozessor 704 ausgeführt werden, sobald er empfangen wurde und/oder kann in der Speichereinrichtung 710 oder einem anderen nicht-flüchtigen Speicher für eine spätere Ausführung gespeichert werden. Auf diese Weise kann das Computersystem 700 Anwendungscode in Form einer Trägerwelle erhalten.
An dieser Stelle sollte darauf hingewiesen werden, daß, auch wenn die Erfindung unter Bezug auf eine spezifische Ausführungsform beschrieben worden ist, dies nicht als eine Beschränkung interpretiert werden sollte. Verschiedene Modifikationen können durch Fachleute auf diesem Gebiet unter der Ausnutzung dieser Offenbarung vorgenommen werden, ohne vom Schutzumfang der Erfindung abzuweichen, der durch die anhängenden Ansprüche bestimmt sein soll.

Claims

Verfahren zum Gewinnen einer deterministischen Antwort für die Speicherzuordnung in einem Computersystem, welches einen Speicherhaufen (102) hat, wobei der Speicherhaufen freien Speicherraum und zugeordneten Speicherraum hat, und wobei das Verfahren aufweist: Zuordnen von vorab zugeordnetem bzw. reserviertem Speicherraum (108) aus dem freien Speicherraum (106) des Haufens, Empfangen einer ersten Speicherzuordnungsanforderung von einem ersten Strang bzw. Faden (414a), und Verarbeiten der ersten Speicherzuordnungsanforderung, indem Speicher aus dem vorab reservierten Speicherraum anstatt aus dem freien Speicherraum in dem Haufen zugeordnet wird.
Verfahren nach Anspruch 1, wobei der vorab zugeordnete (reservierte) Speicherraum zusammenhängend ist und wobei die Verarbeitung der ersten Speicherzuordnungsanforderung ohne Auslösen einer Speicherbereinigung durchgeführt wird.
Verfahren nach Anspruch 2, wobei die erste Anforderung durch Zuordnen zumindest eines Teilsatzes aus dem vorab reservierten Speicherraum bearbeitet wird, und wobei der Teilsatz, nachdem er zugeordnet worden ist, im Zuge eines Speicherbereinigungsvorgangs auf den Haufen zurück freigegeben wird.
Verfahren nach Anspruch 1, welches aufweist: Empfangen einer zweiten Speicherzuordnungsanforderung von einem zweiten Strang bzw. Faden (414b), welcher eine Speicherzuordnung aus dem vorab reservierten Speicherraum anfordert, und Verarbeiten der zweiten Speicherzuordnungsanforderung durch Zuordnen von Speicher aus dem vorab reservierten Speicherraum anstatt aus dem freien Raum des Haufens.
Verfahren nach Anspruch 4, wobei die ersten und zweiten Speicherzuordnungsanforderungen gleichzeitig empfangen werden und wobei vor dem Verarbeiten einer der Anforderungen ein wechselseitiger Ausschlußvorgang durchgeführt wird, um festzulegen, welche Anforderung zuerst bearbeitet wird.
Verfahren nach Anspruch 5, wobei dann, wenn der wechselseitige Ausschlußvorgang durchgeführt worden ist, jede der ersten und zweiten Anforderungen in im wesentlichen gleichen Zeiträumen bearbeitet wird.
Verfahren nach Anspruch 4, wobei die erste Anforderung durch Zuordnen eines ersten Teilsatzes von vorab reserviertem Speicherraum verarbeitet wird, wobei die zweite Anforderung durch Zuordnen eines zweiten Teilsatzes aus dem vorab reservierten Speicherraum bearbeitet wird und wobei die ersten und zweiten Teilsätze, nachdem sie zugeordnet worden sind, im Zuge eines Speicherbereinigungsvorgangs einem Zurückfallen auf den Haufen zurück ausgesetzt sind.
Verfahren nach Anspruch 4, welches weiterhin aufweist: Bestimmen, ob verfügbarer Speicherraum in dem vorab reservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, und in Reaktion auf die Feststellung, daß der verfügbare Speicherraum in dem vorreservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, Zuordnen weiteren reservierten Speicherraumes aus dem freien Speicherraum auf dem Haufen für die Verwendung zur Verarbeitung künftiger Speicherzuordnungsanforderungen.
Computersystem, welches in der Lage ist, eine deterministische Speicherzuordnungsantwort zu erhalten und welches aufweist: einen Speicherhaufen (102), der freien Speicherraum (106) und zugeordneten Speicherraum aufweist, einen Mechanismus (412) zum Zuordnen von vorab reserviertem Speicherraum aus dem freien Speicherraum in dem Haufen, einen Mechanismus (410) zum Empfangen einer ersten Speicherzuordnungsanforderung von einem ersten Strang (414a), und einen Mechanismus zum Verarbeiten der ersten Speicherzuordnungsanforderung durch Zuordnen von Speicher aus dem vorreservierten Speicherraum anstatt aus dem freien Speicherraum in dem Haufen.
System nach Anspruch 9, wobei der vorreservierte Speicherraum zusammenhängend ist und wobei die erste Speicherzuordnungsanforderung ohne Auslösen eines Speicherbereinigungsvorgangs verarbeitet wird.
System nach Anspruch 10, wobei die erste Anforderung durch Zuordnen zumindest eines Teilsatzes des vorreservierten Speicherraumes bearbeitet wird, und wobei der Teilsatz, nachdem er zugeordnet worden ist, über einen Speicherbereinigungsvorgang einem Zurückfallen in den Haufen ausgesetzt ist.
System nach Anspruch 9, welches weiterhin aufweist: einen Mechanismus zum Empfangen einer zweiten Speicherzuordnungsanforderung von einem zweiten Strang (414b), welcher eine Speicherzuordnung aus dem vorreservierten Speicherraum anfordert und einen Mechanismus zum Verarbeiten der zweiten Speicherzuordnungsanforderung durch Zuordnen von Speicher aus dem vorreservierten Speicherraum anstatt aus dem freien Raum in dem Haufen.
System nach Anspruch 12, wobei die ersten und zweiten Speicherzuordnungsanforderungen gleichzeitig empfangen werden und wobei das System weiterhin aufweist: einen Mechanismus zum Durchführen eines wechselseitigen Ausschlußverfahrens vor dem Verarbeiten irgendeiner der Anforderungen, um festzulegen, welche Anforderung zuerst zu bearbeiten ist.
System nach Anspruch 13, wobei dann, wenn das wechselseitige Ausschlußverfahren durchgeführt worden ist, jede der ersten und zweiten Anforderungen in im wesentlichen gleich langen Zeitabschnitten verarbeitet wird.
System nach Anspruch 12, wobei die erste Anforderung durch Zuordnen eines ersten Teilsatzes des vorreservierten Speicherraums bearbeitet wird, während die zweite Anforderung durch Zuordnen eines zweiten Teilsatzes des vorreservierten Speicherraumes bearbeitet wird und wobei die ersten und zweiten Teilsätze, nachdem sie zugeordnet sind, im Wege eines Speicherbereinigungsvorgangs einem Zurückfallen in den Haufen ausgesetzt sind.
System nach Anspruch 12, welches weiterhin aufweist: einen Mechanismus, um festzulegen, ob verfügbarer Speicherraum in dem vorreservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, und einen Mechanismus, um in Reaktion darauf, daß festgestellt wurde, daß der verfügbare Speicherraum in dem vorreservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, aus dem freien Speicherraum in dem Haufen weiterer vorreservierter Speicherraum für die Verwendung zur Verarbeitung künftiger Speicherzuordnungsanforderungen zuzuordnen.
Computerprogrammprodukt zum Erzielen einer deterministischen Spercherzuordnungsantwort in einem System, welches einen Speicherhaufen (102) hat, wobei der Speicherhaufen freien Speicherraum (106) und zugeordneten Speicherraum hat, und wobei das Computerprogrammprodukt aufweist: Code, um zu bewirken, daß einer oder mehrere Prozessoren aus dem freien Speicherraum in dem Haufen einen vorreservierten Speicherraum zuweisen, Code, um einen oder mehrere Prozessoren zu veranlassen, eine erste Speicherzuordnungsanforderung von einem ersten Strang (414a) zu empfangen, und Code, um einen oder mehrere Prozessoren zu veranlassen, die erste Speicherzuordnungsanforderung durch Zuordnen von Speicher aus dem vorreservierten Speicherraum anstatt aus dem freien Speicherraum in dem Haufen zu verarbeiten.
Computerprogrammprodukt nach Anspruch 17, wobei der vorreservierte Speicherraum zusammenhängend ist und wobei die Verarbeitung der ersten Speicherzuordnungsanforderung ohne Auslösen eines Speicherbereinigungsvorgangs ausgeführt wird.
Computerprogrammprodukt nach Anspruch 18, wobei die erste Anforderung verarbeitet wird durch Zuordnen zumindest eines Teilsatzes des vorreservierten Speicherraums und wobei der Teilsatz, nachdem er zugeordnet worden ist, im Wege eines Speicherbereinigungsvorgangs in den Haufen zurückfallen kann.
Computerprogrammprodukt nach Anspruch 17, welches weiterhin aufweist: Code, um einen oder mehrere Prozessoren zu veranlassen, eine zweite Speicherzuordnungsanforderung von einem zweiten Strang (414b) zu empfangen, der eine Speicherzuordnung aus dem vorreservierten Speicherraum anfordert, und Code, um einen oder mehrere Prozessoren zu veranlassen, die zweite Speicherzuordnungsanforderung durch Zuordnen von Speicher aus dem vorreservierten Speicherraum anstatt aus dem freien Raum in dem Haufen zu verarbeiten.
Computerprogrammprodukt nach Anspruch 20, wobei die ersten und zweiten Speicherzuordnungsanforderungen gleichzeitig empfangen werden und wobei das Computerprogrammprodukt weiterhin aufweist: Code, um einen oder mehrere Prozessoren zu veranlassen, vor der Verarbeitung irgendeiner der Anforderungen ein wechselseitiges Ausschlußverfahren durchzuführen, um festzulegen, welche Anforderung zuerst bearbeitet wird.
Computerprogrammprodukt nach Anspruch 21, wobei, nachdem das wechselseitige Ausschlußverfahren durchgeführt worden ist, jede der ersten und zweiten Anforderungen in im wesentlichen gleich langen Zeitabschnitten verarbeitet wird.
Computerprogrammprodukt nach Anspruch 20, wobei die erste Anforderung verarbeitet wird durch Zuordnen eines ersten Teilsatzes des vorreservierten Speicherraums, wobei die zweite Anforderung verarbeitet wird durch Zuordnen eines zweiten Teilsatzes des vorreservierten Speicherraums und wobei die ersten und zweiten Teilsätze, nachdem sie zugeordnet worden sind, im Zuge eines Speicherbereinigungsvorgangs in den Haufen zurückfallen können.
Computerprogrammprodukt nach Anspruch 20, welches weiterhin aufweist: Code, um einen oder mehrere Prozessoren zu veranlassen, festzulegen, ob verfügbarer Speicherraum in dem vorreservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, und Code, um einen oder mehrere Prozessoren zu veranlassen, in Reaktion auf eine Feststellung, daß der verfügbare Speicherraum in dem vorreservierten Speicherraum unter einen gewissen Grenzwert abgesunken ist, aus dem freien Speicherraum in dem Haufen weiteren vorreservierten Speicherraum für die Verwendung bei der Verarbeitung künftiger Speicherzuordnungsanforderungen zuzuordnen.