DE69635728T2

DE69635728T2 - Transparentes, lokales und verteiltes speicherverwaltungssystem

Info

Publication number: DE69635728T2
Application number: DE69635728T
Authority: DE
Inventors: Blaine Redwood City GARST; Ali Redwood City OZER; Bertrand Redwood City SERLET; Trey Redwood City MATTESON
Original assignee: Next Software Inc
Current assignee: Next Software Inc
Priority date: 1995-01-31
Filing date: 1996-01-31
Publication date: 2006-09-14
Anticipated expiration: 2016-02-01
Also published as: US6304884B1; DE69635728D1; EP0807289B1; EP0807289A1; EP0807289A4; US6026415A; WO1996024099A1; US5687370A

Description

HINTERGRUND DER VORLIEGENDEN ERFINDUNG
1. Gebiet der Erfindung
Die Erfindung betrifft das Gebiet objektorientierter Programmierung und verteilter Berechnung.
2. Hintergrundtechnik
Objektorientierte Programmierung ist ein Verfahren, Computerprogramme zu erzeugen, indem bestimmte grundlegende Funktionsbausteine kombiniert und Beziehungen unter und zwischen den Funktionsblöcken erzeugt werden. Die Funktionsblöcke bei objektorientierten Programmiersystemen werden als "Objekte" bezeichnet. Ein Objekt ist eine Programmiereinheit, die eine Datenstruktur und die Operationen (Verfahren oder Prozeduren) zusammengefasst, die diese Daten verwenden oder ändern können. Somit besteht ein Objekt aus Daten und einer oder mehreren Operationen oder Prozeduren, die auf diese Daten angewendet werden können. Ein Objekt kann angewiesen werden, eines seiner Verfahren durchzuführen, wenn es "Nachricht" erhält. Eine Nachricht ist ein Steuerbefehl oder Instruktion für das Objekt, ein bestimmtes Verfahren auszuführen. Sie besteht aus einer Verfahrensauswahl (Name des Verfahrens) und Argumenten (den Variablen in dem Objekt zuzuordnende Werte). Eine Nachricht teilt dem empfangenden Objekt mit, was zu tun ist.
Ein Nachteil der bekannten objektorientierten Programmiersysteme besteht darin, dass alle Objekte in einem einzelnen Programm oder Prozess vorliegen müssen. Dies verhindert es, ein objektorientiertes Programmiersystem zu verwenden, wenn verteilte Anwendungen geschrieben werden. Zusätzlich verhindert diese Einschränkungen der bekannten Technik die Erzeugung von Anwendungen, die physikalisch über Netzwerke von Vorrichtungen verteilt sind. Ein bekanntes Verfahren, um verteiltes objektorientiertes Programmieren bereitzustellen, ist in "Design of a Distributed Object Manager for the SmallTalk-80 System", D. Decouchant, OOPSLA 86 Proceedings, September 1986, Seiten 444–452 beschrieben. Die Decouchant-Entgegenhaltung beschreibt die Auslegung eines verteilten Objektmanagers, der es mehreren SmallTalk-80-Systemen ermöglicht, Objekte in einem lokalen Netzwerk gemeinsam zu nutzen. Wenn ein lokales Objekt mit einem entfernten Objekt kommunizieren möchte, kommuniziert das lokale Objekt mit einem "Proxy", der das entfernte Objekt lokal darstellt. Der Proxy weist zwei Felder auf, die ein entferntes Objekt beschreiben, nämlich die residente Stelle des entfernten Objekts und einen Zeiger zu dem Objekt an der residenten Stelle. Wenn das Objekt, auf das Bezug genommen wird, wandert, werden die Inhalte des Bezug nehmenden Objekts nicht modifiziert. Der Proxy wird dem entsprechend von dem Objektmanager aktualisiert. Bei dieser Implementierung entspricht ein Proxy funktional einer Unix-Verbindung abgesehen davon, dass ein Proxy für den Programmierer nicht sichtbar ist. Es ist wie eine geheime Datenstruktur, die von dem Objektmanager wie andere Small-Talk-Objekte behandelt wird.
In lokalen oder verteilten Objektprogrammierumgebungen erzeugen Objekte regelmäßig andere Objekte und verfügen über diese. Die meiste Zeit erzeugt ein Objekt Objekte für seine eigene Verwendung und verfügt dann über diese wie erforderlich. Wenn jedoch zum Beispiel über einen Aufruf eines Verfahrens eines Quellenobjekts (engl.: source object) das Quellenobjekt ein Objekt erzeugt und dieses zu einem Zielobjekt weitergibt, werden die Informationen über Zuordnung und Verantwortlichkeit hinsichtlich der Verfügung unklar. Nimmt man zum Beispiel an, dass in einer Objekt-C-Umgebung ein als Gadget bezeichnetes Objekt eine Anzahl von als Widgets bezeichneten Objekte enthält und dass ein als Request bezeichnetes Objekt wünscht, auf die Widget-Objekte zuzugreifen, indem das Verfahren aufgerufen wird: – (NSArray *) Widgets. Dieser Aufruf bewirkt, dass zum Beispiel Kopien der Widget-Objekte Speicherplatz zur Verwendung von dem Request-Objekt zugewiesen wird. Dieses Verfahren berücksichtigt jedoch nicht, ob das Gadget-Objekt oder das Request-Objekt sich über den den Widget-Objekten zugeordneten Speicherplatz informiert und über diesen verfügen sollte, nachdem das Request-Objekt die Widget-Objekte nicht mehr braucht.
Es kann eine Konvention dahingehend vereinbart werden, dass entweder das Source-Objekt, d. h. das Gadget-Objekt oder das Ziel-Objekt, d. h. das Request-Objekt dafür verantwortlich ist, über das erzeugte Objekt, d. h. das Widget-Objekt, zu verfügen. Eine solche Konvention erfordert es jedoch, dass der Programmierer ein komplexes Netz an Objekten überwacht, die regelmäßig in Antwort auf einen Aufruf verschiedener Verfahren erzeugt werden. Eine solche Konvention hat auch andere Schwierigkeiten. Zum Beispiel kann in einer verteilten Bearbeitungsumgebung das Source-Objekt in einer lokalen Vorrichtung vorliegen und kann das Ziel-Objekt in einer entfernten Vorrichtung vorliegen. In diesem Fall kann die entfernte Vorrichtung einen Prozess durchführen, der nicht die gleichen Programmierkonventionen wie der lokale Prozess hat. Der entfernte Prozess kann zum Beispiel auf der Grundlage einer anderen Programmiersprache als der des lokalen Prozesses ablaufen. In einer solchen Situation ist es für einen Programmierer der lokalen Vorrichtung sehr schwierig, Objekte, die für die entfernte Vorrichtung erzeugt werden, zu überwachen und über diese zu verfügen. Ein Problem besteht darin, dass das lokale Source-Objekt wissen muss, wenn das Ziel-Objekt mit dem erzeugten Objekt fertig ist, weil es klarer Weise nicht geeignet ist, über das erzeugte Objekt zu verfügen, während es weiterhin von dem Ziel-Objekt verwendet wird. Andererseits ist es schwierig, jedes Ziel-Objekt der entfernten Vorrichtung zu überwachen und Nachrichten zu den Ziel-Objekten zu senden, um über Objekte, die nicht länger benötigt werden, zu verfügen, insbesondere, wenn die Programmierumgebungen der entfernten und lokalen Vorrichtungen unterschiedlich sind. In jedem Fall umfasst ein herkömmlicher Versuch, das Problem Speicherraum zurückzufordern, zu lösen, eine aktive Einbeziehung des Programmierers in die schwierige und komplexe Aufgabe, Speicherplatz zurückzufordern, der Objekten zugeordnet ist, die im Verlauf des Betriebs eines Programms erzeugt werden.
Ein bekannter Versuch zur automatischen Freigabe des Speichers, der Objekten zugeordnet ist, die nicht länger benötigt werden, wird als "Garbage-Collection" (Müllsammlung) bezeichnet. Es ist jedoch schwierig, eine Garbage-Collection in einer vorrichtungsunabhängigen Form in Sprachen (wie zum Beispiel C-basierte Sprachen) bereitzustellen, in denen kein Garbage-Collection eingebaut ist. Zusätzlich ist die Garbage-Collection nicht vorhersagbar und kann ohne Steuerung seitens des Programmierers auftreten, weil eine allgemeine Routine zur Garbage-Collection von einer einzelnen Anfrage aktiviert wird, die jederzeit erzeugt werden kann. Zusätzlich können derzeitige Verfahren zur Garbage-Collection bestimmte Klassen freigegebener Objekte übersehen.
Als zusätzlichen Stand der Technik offenbart der Artikel von Smith et al. "FLAMINGO: WINDOW MANAGEMENT FOR DISTRIBUTED SYSTEMS", PEKING, 23.–27. JUNI 1987, WASHINGTON, IEEE COMPUTER SOC. PRESS, USA, Band CONF. 2, 23. JUNI 1987 (1987-06-23), Seiten 111–117, XP000042683 ein verteiltes Speichermanagementverfahren, bei dem jedes Objekt eine Referenzzählung und eine Liste der entfernten Prozesse aufweist, denen jemals ein Verweis auf dieses Objekt gesendet wurde. Für lokale Verweise wird eine Standardverweiszählung verwendet. Für entfernte Verweise muss jeder entfernte Prozess annehmen, dass eine Verweiszählung mit jedem entfernten Verfahrensaufruf, bei dem ein Objekt als Parameter enthalten ist, erhöht wurde. Der entfernte Prozess muss dann programmiert werden, um explizit diejenigen Verweise freizugeben, die der Prozess nicht zurückbehalten muss. In dem Fall, in dem ein entfernter Prozess nicht so programmiert ist, kann das lokale Objekt nicht freigegeben werden, bis der entfernte Prozess endet, wobei in diesem Fall das entfernte System den Namen des beendeten Prozesses bekannt gibt, so dass andere Systeme den Verweis auf den beendeten Prozess von der Prozessliste der entsprechenden lokalen Objekte löschen können.
Ferner ist auch der Artikel von McCullough, P.L. "TRANSPARENT FORWARDING: FIRST STEPS", ORLANDO, 4.–8. OKT 1987, SPECIAL ISSUE OF SIGPLAN NOTICES, BAND 22, NR. 12, DEZ. 1987, READING, ACM, USA, vol. CONF. 2, 4. OKTOBER 1987 (1987-10-04), Seiten 331–341, XP000299797 als Hintergrundtechnik für Speichermanagement zitiert.
Es besteht daher in der Technik Bedarf an einem effektiven und effizienten Verfahren zum Zurückfordern von Speicherplatz, der Objekten in einer objektorientierten Programmierumgebung zugewiesen ist. Insbesondere besteht Bedarf an einer effektiven und effizienten Weise, um Speicherplatz in einer verteilten Prozessumgebung zurückzuverlangen, wo in einer lokalen Vorrichtung erzeugte Objekte zu einem Ziel-Objekt weitergeleitet werden, das in einer entfernten Vorrichtung vorliegt. Außerdem besteht Bedarf an einem Verfahren, um transparent, d. h. ohne den Programmierer aktiv einzubeziehen, Speicherplatz zurückzufordern, der Objekten zugewiesen ist, die während des Ablaufs eines Programms erzeugt werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Verfahren und ein System zum transparenten lokalen und verteilten Speichermanagement bereit. Die Erfindung strebt danach, die Erfordernisse der bekannten Technik zu überwinden, zu überwachen, ob ein Speicherplatz, der einem neuen Objekt zugewiesen ist, oder ein neues Programm oder Datenstruktur zurückgefordert werden kann.
Dem entsprechend stellt die vorliegende Erfindung ein Speichermanagementverfahren wie in Anspruch 1 definiert und eine Speichermanagementvorrichtung wie in Anspruch 13 definiert bereit.
Bevorzugte, aber nicht einschränkende Merkmale des Verfahrens und der Vorrichtung sind in den abhängigen Ansprüchen definiert.
Die vorliegende Erfindung ist in verteilten Netzwerken brauchbar, wo unterschiedliche Programmierkonventionen auf entfernten und lokalen Vorrichtungen die Speichermanagementaufgabe bekannter Technik besonders schwierig machen. Die vorliegende Erfindung ist auch in einer objektorientierten Programmierumgebung brauchbar.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm eines Computersystems, das verwendet werden kann, um die vorliegende Erfindung auszuführen.
2A und 2B sind Flussdiagramme, die eine Übersicht der vorliegenden Erfindung veranschaulichen.
3–5 zeigen ein Beispiel der Anordnung des Speicherplatzes eines Bildes eines einen neuen Arbeitszyklus bearbeitenden Programmteils.
6 zeigt ein Beispiel eines verteilten Netzwerks, in dem die vorliegende Erfindung ausgeführt wird.
7A–7E zeigen eine Anwendung der vorliegenden Erfindung im Fall eines verteilten Netzwerks.
8 zeigt die Struktur eines Autofreigabepools gemäß der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es ist ein System zum transparenten lokalen und verteilten Speichermanagement beschrieben. In der vorliegenden Beschreibung sind viele spezielle Einzelheiten, wie zum Beispiel objektorientierte Programmiersprache, Betriebssystem, etc., genannt, um für ein eingehenderes Verständnis der vorliegenden Erfindung zu sorgen. Es ist jedoch einem Fachmann auf dem Gebiet ersichtlich, dass die Erfindung ohne diese speziellen Einzelheiten ausgeführt werden kann. In anderen Fällen sind bekannte Merkmale nicht im einzelnen beschrieben, um so die vorliegende Erfindung nicht unverständlich zu machen.
Computersystem zum Implementieren der vorliegenden Erfindung
Die vorliegende Erfindung kann auf jedem herkömmlichen oder allgemein verwendbaren Computersystem implementiert werden. Ein Beispiel einer Ausführungsform eines Computersystems zum Implementieren dieser Erfindung ist in 1 veranschaulicht. Eine Tastatur 10 und eine Maus 11 sind mit einem bidirektionalen System 19 verbunden. Die Tastatur und die Maus dienen dazu, eine Benutzereingabe in das Computersystem einzugeben und diese Benutzereingabe zu einer CPU 13 zu übertragen. Das Computersystem von 1 weist auch einen Videospeicher 14, einen Hauptspeicher 15 und einen Massenspeicher 12 auf, die alle zusammen mit der Tastatur 10, der Maus 11 und der CPU 13 mit dem bidirektionalen Systembus 19 verbunden sind. Der Massenspeicher 12 kann sowohl ortsfeste als auch entfernbare Medien aufweisen, wie zum Beispiel magnetische, optische oder magneto-optische Speichersysteme oder jede andere verfügbare Massenspeichertechnologie. Der Massenspeicher kann in einem Netzwerk gemeinsam genutzt sein oder ein speziell zugeordneter Massenspeicher sein. Der Bus 19 kann zum Beispiel 32 Adressleitungen zum Adressieren des Videospeichers 14 oder des Hauptspeichers 15 enthalten. Der Systembus 19 weist zum Beispiel auch einen 32-Bit Datenbus auf, um Daten zwischen und unter den Komponenten zu übertragen, wie zum Beispiel der CPU 13, der Hauptspeicher 15, der Videospeicher 14 und der Massenspeicher 12. Alternativ können Multiplex-Daten/Adress-Leitungen anstelle separater Daten- und Adressleitungen verwendet werden.
Bei der bevorzugten Ausführungsform dieser Erfindung ist die CPU 13 ein von Motorola hergestellter 32-Bit Mikroprozessor, wie zum Beispiel der 68030 oder 68040. Es kann jedoch jeder andere geeignete Mikroprozessor oder Mikrocomputer verwendet werden. Der Motorola-Mikroprozessor und sein Befehlssatz, Busstruktur und Steuerleitung MC68030 Benutzerhandbuch und dem MC68040 Benutzerhandbuch beschrieben, die von Motorola Inc., Phoenix, Arizona veröffentlicht sind. Der Hauptspeicher 15 umfasst typischer Weise einen Speicher mit wahlfreiem Zugriff (RAM) und umfasst bei der bevorzugten Ausführungsform dieser Erfindung einen Speicher von 8 Megabyte. Es kann mehr oder weniger Speicher verwendet werden, ohne sich dabei vom Umfang dieser Erfindung zu entfernen. Der Videospeicher 14 ist ein Videospeicher mit wahlfreiem Zugriff (RAM) mit zwei Anschlüssen und besteht bei dieser Erfindung zum Beispiel aus 256 k Byte Speicher. Es kann jedoch mehr oder weniger Videospeicher vorgesehen sein. Ein Anschluss des Videospeichers 14 ist mit einem Videomultiplexer und einem Schieber 16 verbunden, der wiederum mit einem Videoverstärker 17 verbunden ist. Der Videoverstärker 17 wird verwendet, um einen Kathodenstrahlröhren-(CRC; engl.: cathode ray tube)-Rastermonitor 18 anzusteuern. Die Video-Multiplexer-Schieber-Schaltkreisanordnung 16 und der Videoverstärker 17 sind in der Technik bekannt und können mittels beliebiger geeigneter Mittel implementiert werden. Diese Schaltkreisanordnung wandelt in dem Videospeicher 14 gespeicherte Pixeldaten in ein Rastersignal um, das zur Verwendung durch den Monitor geeignet ist. Der Monitor 18 ist ein Typ eines Monitors, der geeignet ist, um graphische Bilder wiederzugeben. Das oben beschriebene Computersystem dient lediglich als Beispiel. Die vorliegende Erfindung kann in jedem Typ eines Computersystems oder Programmier- oder Bearbeitungsumgebung implementiert sein.
Die bevorzugte Ausführungsform der vorliegenden Erfindung implementiert eine objektorientierte Programmiersprache, wie zum Beispiel die objektive C-Sprache (engl.: objective C language). Objektives C ist eine Erweiterung von ANSI C, die die Definition von Klassen von Objekten unterstützt und eine syntaktische und Laufzeitunterstützung bereitstellt, um Nachrichten an Objekte zu senden. Dieses Sprachmodell ist teilweise von SmallTalk abgeleitet und ist in "Object-Oriented Programming; An Evolutionary Approach", Brad J. Cox, Addison-Wesley, 1986 und in "SmallTalk-80: The Language and its Implementation", Adele Goldberg, Dave Robson, Addison-Wesley, 1983 beschrieben worden. In seiner bevorzugten Ausführungsform ist die vorliegende Erfindung ferner in einem Computersystem implementiert, das ein objektorientiertes Betriebssystem nutzt. Ein solches objektorientiertes Betriebssystem ist als das "Mach"-Betriebssystem bekannt und in von NeXT, Inc., Anmelderin der vorliegenden Erfindung, verkaufter Software zur Verwendung auf "PC"-Hardware und anderen Computern implementiert, die von verschiedenen Herstellern (zum Beispiel Hewlett und Sun Microsystems) verkauft werden. Das Mach-Betriebssystem ist ein objektorientiertes Betriebssystem, das verteiltes Programmieren unterstützt. Es ist ein Multicasting-Betriebssystem-Kernel, das mehrere, unabhängige "Programmteile" zulässt, die die grundlegende Umgebung eines Programms bereitstellen. Mach unterstützt eine Nachrichtenübermittlung innerhalb und zwischen Programmteilen.
Übersicht der vorliegenden Erfindung
Das Flussdiagramm der 2A und 2B ist eine Übersicht des transparenten lokalen und verteilten Speichermanagementsystems der vorliegenden Erfindung. In Schritt 101 wartet das System der vorliegenden Erfindung auf ein Ereignis, das einen "Arbeitszyklus" auslöst. Ein Arbeitszyklus ist ein Begriff, der auf einen Zeitraum einer Aktivität eines Anwendungsprogramms bezeichnet, dem ein Zeitraum mit Inaktivität folgt. Bei einer lokalen Anwendung, die eine Fenster erzeugende Schnittstelle aufweist, wird zum Beispiel ein neuer Arbeitszyklus in Antwort auf eine Benutzereingabe, wie zum Beispiel das Drücken einer Taste, einer Maus oder eines Knopfs, ausgelöst. Als weiteres Beispiel wird in einem verteilten Netzwerk ein neuer Arbeitszyklus ausgelöst, wenn eine entfernte Vorrichtung eine lokale Vorrichtung anfragt, um anstelle der entfernten Vorrichtung aktiv zu werden. Die Erfindung nutzt diese "natürlich auftretenden" Arbeitszyklen, um ein neues Objekt zu erzeugen, das als der "Autofreigabepool" (engl.: autorelease pool) bezeichnet wird (auch als "Autofreigabeobjekt" oder "Autofreigabeprogramm" bei dieser Anwendung bezeichnet). Wie in Schritt 103 gezeigt wird, wenn ein neuer Arbeitszyklus ausgelöst wird, ein neuer Autofreigabepool erzeugt (Schritt 105), ansonsten wartet das System auf ein Ereignis, das einen neuen Arbeitszyklus auslöst (Schritt 101).
In Schritt 107 wird ein Objekt (als Zielobjekt bezeichnet) in Antwort auf das Ereignis erzeugt, das den Arbeitszyklus auslöst. Beispielsweise wird in Antwort auf einen Maus-Druck (das auslösende Ereignis) ein Objekt, das erforderlich ist, um ein "Pop-Up-Menü" erzeugt, indem zum Beispiel eine Unterroutine ausgeführt wird. In Schritt 109 wird Speicherplatz, typischer Weise ein Platz im RAM, das zu dem Programmteil gehört, während der das Maus-Ereignis aufgetreten ist, zugewiesen, um das Ziel-Objekt zu speichern. In Schritt 111 "behält" der in Schritt 105 erzeugte, neue Autofreigabepool das Ziel-Objekt bei. Ein Objekt, wie zum Beispiel der Autofreigabepool, kann ein anderes Objekt beibehalten, wie zum Beispiel das Ziel-Objekt, indem ein Zeiger auf dieses Objekt gespeichert wird. Ein Zeiger, der auch als "ID" (Identifikationsdaten) bezeichnet wird, ist die Adresse, an der ein Objekt lokalisiert ist. Daher behält der Autofreigabepool das Ziel-Objekt bei, indem die Adresse des Ziel-Objekts gemerkt wird. Dem gegenüber unterhält das Ziel-Objekt eine Zählung, die als "Referenzzählung" bezeichnet wird, die die Anzahl von Objekten angibt, die das Ziel-Objekt derzeit beibehalten (Schritt 113). Daher entspricht während des Verlaufs eines Arbeitszyklus die von dem Ziel-Objekt unterhaltende Referenzzählung 1 oder ist größer als 1, weil wenigstens ein Objekt (d. h. der Autofreigabepool) das Ziel-Objekt beibehält. Wenn während des Verlaufs des Arbeitszyklus andere Objekte ebenfalls das Ziel-Objekt beibehalten, dann wäre die Referenzzählung größer als 1.
Der Arbeitszyklus ist abgeschlossen, wenn die Aktivität des Computersystems in Antwort auf ein auslösendes Ereignis, wie zum Beispiel ein Maus-Druck, beendet ist. Wenn der Arbeitszyklus abgeschlossen ist (Schritt 115), wird der Autofreigabepool automatisch entfernt (Schritt 117). Folglich gibt es nicht länger einen Autofreigabepool, der das Ziel-Objekt speichert, und daher wird die von dem Ziel-Objekt unterhaltene Referenzzählung um eins verringert. Es können jedoch andere Objekte, die das Ziel-Objekt "beibehalten" haben, dieses ebenfalls "freigegeben" haben (d. h. sie behalten das Ziel-Objekt nicht bei). In diesem Fall wird für jedes Objekt, das das Ziel-Objekt freigegeben hat, die Referenzzählung um eins verringert (Schritt 119). Bei Schritt 121 überprüft das System, ob die Referenzzählung gleich Null ist. Ist dies der Fall, ist der dem Ziel-Objekt zugewiesene (RAM)-Platz freigegeben (Schritt 123). Mit anderen Worten, das Ziel-Objekt wird von dem Speicherplatz des Programmteils gelöscht, während der das Maus-Ereignis aufgetreten ist. Wenn die Referenzzählung nicht gleich Null ist, bleibt das Ziel-Objekt in dem Speicherplatz des aktuellen Programmteils zurück, bis kein Objekt das Ziel-Objekt beibehält. Somit überprüft das System kontinuierlich die Referenzzählung, bis die Referenzzählung gleich Null ist, wo der dem Ziel-Objekt zugewiesene Speicherplatz freigegeben wird. Die Freigabe von Speicherplatz wird erreicht, ohne dass dabei der Programmierer überwachen muss, ob das neu erzeugte Objekt (d. h. das Ziel-Objekt) weiterhin von der Unterroutine benötigt wird, die das Ziel-Objekt erzeugt hat, oder von anderen Objekten, die das Ziel-Objekt beibehalten haben. Dem entsprechend wird das Speichermanagement der vorliegenden Erfindung transparent für den Programmierer ausgeführt. Die vorliegende Erfindung ist unten detaillierter beschrieben.
Speichermanagement von der vorliegenden Erfindung in einem lokalen Fall
3 zeigt die Organisation eines Speichers, der ein "Bild" eines aktuellen Programmteils in einer lokalen Vorrichtung umfasst (jeder Programmteil hat eine andere Sicht des RAM-Platzes einer Vorrichtung. Diese andere Ansicht eines Speichers wird als das "Bild" (engl.: image) dieses Programmteil bezeichnet). Ein Beispiel eines Ereignisses, das einen neuen Arbeitszyklus in einer lokalen Vorrichtung auslöst, ist ein Maus-Ereignis 203. Ein Maus-Ereignis 203 ist zum Beispiel ein Maus-Druck, der eine Anzeige eines Pop-Up-Menüs in ei nem aktiven Fenster einer lokalen Anwendung auslöst. Der Maus-Druck löst somit einen neuen Arbeitszyklus aus, der der Zyklus ist, in dem die Anwendung das Pop-Up-Menü aufruft und es auf dem Bildschirm wiedergibt. Das Maus-Ereignis ist transient (und gehört zu einem in 3 gezeigten "transienten Speicher" 201) und wird somit am Ende des Arbeitszyklus entfernt, nämlich wenn das Pop-Up-Menü auf dem Bildschirm angezeigt wird. Daher ist das Überwachen und Entfernen des Maus-Ereignisses selbst eine relativ einfache Angelegenheit. Das Bild des aktuellen Programmteils umfasst auch einen "dauerhaften Speicher" 205, der typischer Weise länger als der von dem Maus-Ereignis 203 ausgelöste Arbeitszyklus dauert. Der dauerhafte Speicher 205 kann ein Hauptfenster 209, ein Unterfenster 207 und ein Unterfenster 211 aufweisen. Während des Arbeitszyklus des Maus-Ereignisses verarbeitet eine Unterroutine der Anwendung das Maus-Ereignis und gibt ein Pop-Up-Menü zurück. Eines der Objekte, da in Antwort auf das Maus-Ereignis aufgerufen und dem Bild des aktuellen Programmteils zugewiesen wird, ist ein in 4 gezeigtes Pop-Up-Menü 213. Pop-Up-Menüs gehören typischer Weise zu einem dauerhafteren Speicher als das Maus-Ereignis, weil andere Objekte, wie zum Beispiel das in 4 gezeigte Unterfenster 211 fordern können, das Pop-Up-Menü über den Arbeitszyklus des Maus-Ereignisses hinaus beizubehalten und anzuzeigen. Das Unterfenster 211 hat das Pop-Up-Menü-Objekt jedoch nicht aufgerufen oder erzeugt. Ferner kann das Unterfenster 211 sogar das Pop-Up-Menü-Objekt nicht über den Arbeitszyklus des Maus-Ereignisses hinaus benötigen. Bei der bekannten Technik hat der Programmierer die Belastung, den Speicherplatz zu überwachen, der dem Pop-Up-Menü-Objekt zugewiesen ist.
Bei dem vorliegenden Beispiel muss der Programmierer nach regelmäßigem Prüfen das Pop-Up-Menü entfernen, um zu gewährleisten, dass der Arbeitszyklus des Maus-Ereignisses aufgehört hat und dass kein anderes Objekt das Pop-Up-Menü beibehält. Der Autofreigabepool der Erfindung überwindet diese Schwierigkeit der bekannten Technik, indem das Pop-Up-Menü während des Verlaufs des Arbeitszyklus des Maus-Ereignisses automatisch beibehalten wird. Am Ende des Arbeitszyklus des Maus-Ereignisses wird der Autofreigabepool entfernt, wobei eine automatische Freigabe des Pop-Up-Menüs bewirkt wird, wenn kein anderes Objekt das Pop-Up-Menü beibehält. Somit wird für den Programmierer transparent dem Pop-Up-Menü zugewiesener Speicherplatz am Ende des Arbeitszyklus des Maus-Ereignisses freigegeben.
Daher umfasst, wie in 5 gezeigt, der dauerhafte Speicher nun das Unterfenster 207, das Hauptfenster 209 und das Unterfenster 211 ohne das Pop-Up-Menü 213. Wenn jedoch andere Objekte, wie zum Beispiel das Unterfenster 211 in dem dauerhaften Speicher 205 benötigt, das Pop-Up-Menü 213 über den Arbeitszyklus des Maus-Ereignisses hinaus beizubehalten, wird das Pop-Up-Menü nicht entfernt, auch wenn der Autofreigabepool am Ende des Arbeits zyklus des Maus-Ereignisses entfernt wird. Daher ermöglicht es die Erfindung, wiederum ohne aktive Einbeziehung des Programmierers, das Pop-Up-Menü beizubehalten, wenn andere Objekte wünschen, das Pop-Up-Menü über den Arbeitszyklus des Maus-Ereignisses hinaus beizubehalten.
Bei einer anderen Ausführungsform betrifft die Erfindung einen anderen Typ einer Speicherzuweisung, ob ein Ziel-Objekt einbezogen ist oder nicht. Ferner kann der zugewiesene Speicherplatz von einem anderen Stück Code oder Programm im Gegensatz zu einem anderen Objekt beibehalten werden. Es wird zum Beispiel angenommen, dass ein String von Daten (im Gegensatz zu einem Objekt), der den Titel eines Fensters bildet, aufgerufen wird und RAM-Platz zugewiesen bekommt. Ein "Fenster-Code" behält diesen String bei, mit anderen Worten, der Fenster-Code erhöht die Referenzzählung für diesen String um Eins. Der Fenster-Code kann dann eine Operation bezüglich des Strings von Daten durchführen, wie zum Beispiel alle Kleinbuchstaben in Großbuchstaben zu ändern. Der String für Großbuchstaben wird über den Arbeitszyklus hinaus beibehalten, der den String für Kleinbuchstaben aufgerufen hat, weil der Großbuchstaben-String als Titel des Fensters angezeigt werden soll.
Am Anfang des Arbeitszyklus, der den String für Kleinbuchstaben aufgerufen hat, wird ein Autofreigabepool erzeugt, der einen Zeiger auf den String für Kleinbuchstaben speichert (d. h. beibehält). Wenn die Umwandlung des String für Kleinbuchstaben in einen String für Großbuchstaben abgeschlossen ist, mit anderen Worten am Ende des Arbeitszyklus, der den String für Kleinbuchstaben aufgerufen hat, wird der Autofreigabepool entfernt. Folglich wird die Referenzzählung für den String für Kleinbuchstaben auf Null reduziert und der dem String für Kleinbuchstaben zugewiesene Speicherplatz wird ohne Einbeziehung des Programmierers zurückgewonnen. Daher ermöglicht die Erfindung eine transparente Wiederbenutzbarmachung von Speicherplatz, der Nicht-Objekten sowie Objekten zugewiesen wurde. Die Erfindung betrifft im Allgemeinen das Wiederbenutzbarmachen von Speicherplatz, der in einer beliebigen Situation zugewiesen wurde, wo neuer Speicherplatz als Folge eines Aufrufs einer Routine, Unterroutine, Prozedur oder eines Programms zugewiesen wird, der eine temporäre Benutzung von RAM-Platz erfordert.
Speichermanagement durch die Erfindung in einem Fall eines verteilten Netzwerks
Das generelle Problem beim Wiederbenutzbarmachen von Speicher, der als Ergebnis einer Netzwerkaktivität zugewiesen wurde, ist in 6 veranschaulicht. Man nehme an, dass ein Programmteil A auf einer lokalen Vorrichtung 251 abläuft, während ein Programmteil B auf einer entfernten Vorrichtung 257 abläuft. Der Programmteil B fordert, eine Unterroutine aufzurufen, die Daten benötigt, die im Bild des Programmteils A vorliegt (es wird daran erinnert, dass das Bild des Programmteils A die Ansicht des RAM aus Sicht des Programmteils A ist). Diese für den Programmteil B interessierenden Daten sind durch Block 253 in 6 gezeigt. Der Programmteil B fordert den Proxy des Programmteils A (d. h. Proxy 259 in 6, der in dem Programmteil B vorliegt) auf, eine Routine des Programmteils A aufzurufen. Der Proxy 259 des Programmteils A leitet die Anfrage, die Unterroutine aufzurufen, an den Programmteil A über eine Netzwerkkommunikationsverbindung 255 weiter. Der Programmteil A arbeitet die Unterroutine auf "für den Programmteil B interessierende Daten" 253 ab und gibt das Ergebnis über die Netzwerkkommunikationsverbindung 255 an den Programmteil B zurück. Als Folge des Abarbeitens dieser Unterroutine wird jedoch etwas Speicherplatz in dem Programmteil A dem Ergebnis der Unterroutine zugewiesen. Dieser Speicherplatz wird in Antwort auf die Anfrage des Programmteils B von einer entfernten Vorrichtung zugewiesen. Gemäß der bekannten Technik kann der Programmteil A diesen Speicherplatz nicht einfach wieder nutzbar machen, weil der Programmteil A gewährleisten muss, dass der Programmteil B nicht länger auf diesen Speicherplatz zugreifen muss, der das Ergebnis der Unterroutine enthält, die in Antwort auf den Abruf von einer entfernten Vorrichtung abgearbeitet wurde. Andererseits kann der Programmteil B diesen Speicherplatz nicht einfach wieder nutzbar machen. Eine Schwierigkeit besteht darin, dass die Programmierkonventionen der entfernten Vorrichtung 257 und der lokalen Vorrichtung 251 unterschiedlich sein können. Ferner muss der Programmteil B ebenfalls gewährleisten, dass der Programmteil A den Speicherplatz nicht länger benötigt, der dem Ergebnis der abgearbeiteten Unterroutine zugewiesen wurde. Daher muss ein Programmierer der bekannten Technik kontinuierlich die verschiedenen Codes und Objekte überwachen, die den Speicherplatz benötigen können, der dem Ergebnis der Unterroutine zugewiesen wurde, bevor dieser Speicherplatz freigegeben (d. h. wieder nutzbar gemacht) wird.
Die vorliegende Erfindung überwindet diese Schwierigkeit der bekannten Technik. Gemäß der vorliegenden Erfindung überwacht ein Autofreigabepool den Speicher, der von dem Programmteil A in Antwort auf den Unterroutinenaufruf von dem Programmteil B zugewiesen wird. Ein Autofreigabepool wird am Anfang des Arbeitszyklus erzeugt, was der Zeitpunkt ist, an dem der Programmteil B den Proxy des Programmteils A auffordert, eine Unterroutine des Programmteils A aufzurufen. Zu diesem Zeitpunkt speichert der Autofreigabepool einen Zeiger auf den Speicher, der von dem Programmteil A dem Ergebnis der Unterroutine zugewiesen wurde. Am Ende des Arbeitszyklus, nämlich wenn eine Kopie des Ergebnisses an den Programmteil B weitergeleitet wird, wird der Autofreigabepool entfernt. Folglich wird die Referenzzählung, die in dem Speicher unterhalten wird, der dem Ergebnis der Subroutine zugewiesen wurde, um Eins verringert. Wenn kein anderes Objekt in dem Programmteil A oder in dem Programmteil B aktuell das Ergebnis der Unterroutine beibehält, wäre die Referenzzählung gleich Null. Folglich kann der dem Ergebnis der Unterroutine zugewiesene Spei cher nun sicher transparent für den Programmierer und unabhängig unterschiedlicher Programmierkonventionen wieder nutzbar gemacht werden, die auf der entfernten Vorrichtung 257 und der lokalen Vorrichtung 251 vorliegen können. Gemäß der bekannten Technik steht dem Programmierer kein transparenter Mechanismus zur Verfügung, um ein solches Verfahren, den zugewiesenen Speicher wieder nutzbar zu machen, zu unterstützen. Die Konvention bekannter Technik "Aufrufender gibt frei" zwingt alle Zulieferer von Unterroutinen dazu, Ergebnisse mit "zusätzlichen Referenzen" zu liefern. Dies resultiert in einem Verlust an Effizienz und Transparenz.
Bezug nehmend auf die 7A bis 7E wird ein weiteres Beispiel berücksichtigt, wie die vorliegende Erfindung in einer verteilten Netzwerkumgebung arbeitet. Wie in 7A gezeigt, wird ein Programmteil A auf einer lokalen Vorrichtung 261 abgearbeitet und ein Programmteil B auf einer entfernten Vorrichtung 267. Der Programmteil A hält einen Proxy 265 für den Programmteil B. Der Programmteil A leitet einen "Aufruf einer entfernten Prozedur" für den Programmteil B ein, indem der Proxy 265 aufgefordert wird, eine Netzwerknachricht zu dem Programmteil B weiterzuleiten. (Ein Aufruf für eine entfernte Prozedur ist ein geeignetes Verfahren, die Netzwerkkommunikationsverbindung (in den 7A bis 7E nicht gezeigt) zwischen der lokalen Vorrichtung 261 und der entfernten Vorrichtung 267 zu verwenden. Die Erfindung ist nicht darauf beschränkt oder hängt nicht davon ab, einen Aufruf für entfernte Prozeduren zu verwenden.)
Wenn der Aufruf für eine entfernte Prozedur von dem Programmteil A eingeleitet ist, beginnt ein neuer Arbeitszyklus und die Netzwerknachricht (Netzwerknachricht 263 in 7B) wird erzeugt und ein Autofreigabepool (nicht gezeigt) wird ebenfalls erzeugt, der einen Zeiger auf die Netzwerknachricht 263 speichert. Dann wird eine Kopie der Netznachricht 263 (als Netzwerknachricht 269 in 7C gezeigt) über die Netzwerkkommunikationsverbindung zu der entfernten Vorrichtung 267 weitergeleitet. Die Netzwerknachricht wird in den Programmteil B der entfernten Vorrichtung 267 kopiert. Diese Kopie ist in 7D als Netzwerknachricht 271 gezeigt.
Der Programmteil B erzeugt seinen eigenen Autofreigabepool (nicht gezeigt) in Antwort auf den Empfang der Netzwerknachricht, was der Anfang eines neuen Arbeitszyklus für den Programmteil B ist. Dieser Autofreigabepool speichert einen Zeiger auf die Netzwerknachricht 271. Der Programmteil B führt dann die Prozedur, die von dem Programmteil A nachgefragt wurde, durch und gibt das Ergebnis dieser Prozedur an den Programmteil A zurück. Die Schritte, die erforderlich sind, um die Rückgabe des Ergebnisses der Prozedur an den Programmteil A durchzuführen, sind in den Figuren nicht gezeigt und werden hier nicht diskutiert, um einfach zu bleiben.
Nachdem die Netzwerknachricht den Programmteil B erreicht hat und in diesen kopiert wurde, endet der Arbeitszyklus des Programmteils A, der von dem Aufruf einer entfernten Prozedur ausgelöst wurde. Dem entsprechend wird der Autofreigabepool in dem Programmteil A, der auf die Netzwerknachricht 263 gezeigt hat, entfernt. Folglich wird der Speicherplatz in dem Programmteil A, der von der Netzwerknachricht 263 besetzt ist, wieder nutzbar gemacht. Andererseits, wenn das Ergebnis der Prozedur, die von dem Programmteil A aufgerufen wurde, zu diesem Programmteil von dem Programmteil B zurückgegeben wurde, endet der Arbeitszyklus, der begonnen hat, als die Netzwerknachricht 271 von dem Programmteil B empfangen wurde. Dem entsprechend wird der Autofreigabepool in dem Programmteil B, der auf die Netzwerknachricht 271 zeigte, entfernt. Folglich wird der Speicherplatz in dem Programmteil B, der von der Netzwerknachricht 271 besetzt ist, wieder nutzbar gemacht.
Wie in 7E gezeigt, werden sowohl der Programmteil A als auch der Programmteil B in dem gleichen Speicherzustand zurückgelassen, der bestand, bevor die Netzwerknachricht erzeugt wurde. Dem entsprechend müssen gemäß unserer Erfindung die Mechanismen, die verwendet wurden, um Objekte, wie zum Beispiel die Netzwerknachricht, zu verteilen, nicht den gesamten Speicher zu überwachen, der den verteilten Objekten in den verschiedenen Vorrichtungen in dem Netzwerk zugewiesen wird: alle Prozesse zum Wiedernutzbarmachen von Speicher werden für den Programmierer transparent durchgeführt.
Als anderes Beispiel, wie die vorliegende Erfindung in einem verteilten Netzwerk arbeitet, wird angenommen, dass die Prozedur, die von der Netzwerknachricht in dem obigen Beispiel aufgerufen wurde, den Programmteil B auffordert, ein "Farbobjekt" zu bilden; ein Objekt dessen einzige Absicht darin besteht, dass das Objekt eine bestimmte Farbe angibt, zum Beispiel die Farbe rot. Das Ergebnis der Unterroutine, nämlich das Farbobjekt, wird dann an den Programmteil A zurückgegeben, mit anderen Worten, das Farbobjekt wird von dem Programmteil B zu dem Programmteil A kopiert. Am Ende des Arbeitszyklus des Programmteils B, d. h. wenn das Farbobjekt an den Programmteil A zurückgegeben wurde, wird der Autofreigabepool in dem Programmteil B, der auf das Farbobjekt gezeigt hat, entfernt. Dem entsprechend wird, wenn keine anderen Objekte derzeit das Farbobjekt in dem Programmteil B beibehalten, der Speicherplatz in dem Programmteil B, der dem Farbobjekt zugewiesen ist, wieder nutzbar gemacht. Wiederum wird der Speicherplatz ohne aktive Einbeziehung des Programmierers wieder nutzbar gemacht.
Als weitere Variation des obigen Beispiels wird angenommen, dass, anstatt dass der Programmteil B (den Programmteil) A mit einer Kopie des Farbobjekts versorgt, der Programmteil B den Programmteil A mit einem Proxy zu dem Farbobjekt versorgt. In diesem Fall spei chert der von der Erfindung erzeugte Autofreigabepool einen Verweis (tatsächlich den einzigen Verweis) zu dem neuen Farbobjekt in dem Programmteil B. Wenn der Proxy zu dem Farbobjekt am Ende des aktuellen Arbeitszyklus des Programmteils A nicht beibehalten wird, wird der Proxy zu dem Farbobjekt freigegeben und eine Netzwerknachricht wird gesendet, um das in dem Programmteil B gebildete Farbobjekt freizugeben. Für den Programmierer stellt sich das Verhalten des verteilten Systems so dar, dass der Programmteil A und der Programmteil B beide lokale Programmteile sind oder als ob der Programmteil A und der Programmteil B nicht unterscheidbare Programmteile wären. Unabhängig davon, ob der Programmteil B eine Kopie des Farbobjekts dem Programmteil A zuführt oder der Programmteil B dem Programmteil A einen Proxy zu dem Farbobjekt zuführt, gibt daher gemäß der vorliegenden Erfindung ein für den Programmierer transparenter Mechanismus den Speicher wieder frei, der entweder dem Programmteil A oder dem Programmteil B zugewiesen ist.
Bei einer Ausführungsform beseitigt die Erfindung die Notwendigkeit einer zusätzlichen Netzwerknachricht, die angibt, dass ein bestimmter Speicherplatz von einer der Vorrichtungen in dem Netzwerk wieder nutzbar gemacht worden ist. Dies wird "Huckepack nehmen" (engl.: piggy backing) einer Speicherstatusnachricht auf das Hauptobjekt oder -nachricht bezeichnet, die über das Netzwerk weitergeleitet wird. Man nehme zum Beispiel an, dass, bei dem obigen Beispiel des Farbobjekts, der Programmteil B den Programmteil A darüber informieren muss, dass der Speicherplatz, den der Programmteil B dem Farbobjekt zugeordnet hat, wieder nutzbar gemacht worden ist. Bei der bekannten Technik sendet der Programmteil B, nachdem das Farbobjekt zu dem Programmteil A zurückgegeben wurde und nachdem der Programmteil B den Speicherplatz in dem Programmteil B, der dem Farbobjekt zugewiesen wurde, wieder nutzbar gemacht hat, eine nachfolgende Netzwerknachricht zu dem Programmteil A, dass der Speicherplatz in dem Programmteil B tatsächlich wieder nutzbar gemacht worden ist.
Im Gegensatz dazu nimmt gemäß der Erfindung der Programmteil B, wenn der Programmteil B das Farbobjekt zu dem Programmteil A zurückgibt, eine zusammen mit dem Farbobjekt gesendete Nachricht Huckepack; die Nachricht gibt dann an, dass das einzige Objekt, das derzeit das Farbobjekt in dem Programmteil B beibehält, der Autofreigabepool ist. Wenn der Programmteil A das Farbobjekt von dem Programmteil B empfängt, würde dem entsprechend der Programmteil A auch wissen, dass der Programmteil B am Ende des Arbeitszyklus des Programmteils B (d. h. wenn das Farbobjekt zu dem Programmteil A zurückgegeben wurde) den Speicherplatz in dem Programmteil B wieder nutzbar gemacht hat, der dem Farbobjekt zugewiesen wurde. Daher überwindet die Erfindung die Forderung der bekannten Technik, eine nachfolgende Nachricht ausgehend von dem Programmteil B zu dem Programmteil A zu senden, die angibt, dass der Speicherplatz von dem Programmteil B wieder nutzbar gemacht wurde.
Struktur eines einzelnen Autofreigabepools
Der Autofreigabepool der vorliegenden Erfindung ist typischer Weise ein Standardobjekt. 8 zeigt ein Beispiel des Autofreigabepools der Erfindung. Der Autofreigabepool 221 enthält Zeiger zu oder Adressen (auch als "IDs" bezeichnet) von anderen Objekten. Der Zeiger auf A (223), der Zeiger auf B (225) und der Zeiger auf C (227) sind Beispiele von Zeigern, die der Autofreigabepool für das Objekt A (229), das Objekt B (235) bzw. das Objekt C (241) speichert. Jeder Zeiger in dem Autofreigabepool 221 besetzt typischer Weise zwischen vier und zweiunddreißig Byte Speicher. Die Objekte, für die Zeiger von dem Autofreigabepool gespeichert werden, sind diejenigen, die typischer Weise infolge eines Aufrufs einer Unterroutine entweder lokal oder ausgehend von einer entfernten Vorrichtung in einem Netzwerk erzeugt werden. Gemäß der Erfindung löst das Ereignis, das einen neuen Arbeitszyklus auslöst, auch die Erzeugung eines neuen Autofreigabepools und das Hinzufügen des neuen Autofreigabepools zu einem Stapel von Autofreigabepools aus. Jedes Objekt, das von einer Datenbasis aufgerufen wird und dem RAM-Platz zugewiesen wird (auch als "Zielobjekt" in dieser Anmeldung bezeichnet), unterhält eine "Referenzzählung", die die Anzahl von Objekten angibt, die derzeit dieses Objekt beibehalten. Aufgrund des Autofreigabepools der Erfindung, der einen Zeiger zu einem Zielobjekt speichert (d. h. beibehält), erhöht daher das beibehaltene Zielobjekt seine Referenzzählung um Eins, was angibt, dass ein Objekt mehr, nämlich der Autofreigabepool, derzeit das Zielobjekt beibehält. Dadurch wird gemäß unserer Erfindung, sobald einem Zielobjekt RAM-Platz zugewiesen wird, die von dem Zielobjekt unterhaltene Referenzzählung gleich oder größer als 1, weil wenigstens ein Objekt (d. h. der Autofreigabepool) das Zielobjekt beibehält. Wie in 8 gezeigt, unterhält das Objekt A (229) eine Referenzzählung 231, wobei eine Zählung von eins dem Autofreigabepool 221 entspricht, die als "A.R.P." 233 gezeigt ist. In vergleichbarer Weise unterhält das Objekt B (235) eine Referenzzählung 237, wobei eine Zählung von eins dem Autofreigabepool 221 entspricht, angegeben durch "A.R.P." 239. Auch das Objekt C (241) unterhält eine Referenzzählung 243 mit einer Zählung von eins, die dem Autofreigabepool 221 entspricht, als "A.R.P." 245 gezeigt.
Erzeugung des Autofreigabepools
Sowohl in Fällen lokaler als auch verteilter Netzwerke werden Autofreigabepools in Antwort auf übergeordnete und untergeordnete Arbeitszyklen erzeugt. Am Anfang jedes Arbeitszyklus wird ein neuer Autofreigabepool erzeugt und jeder Arbeitszyklus hat seinen eigenen Autofreigabepool. Daher gibt es während des Ablaufs eines Programmteils eine Anzahl von ver netzten Autofreigabepools, die verschiedenen Arbeitszyklen entsprechen. Dem entsprechend weist jeder Programmteil eine Gruppe vernetzter Autofreigabepools in dem Bild des Programmteils in dem RAM auf. Die Gruppe von vernetzten Autofreigabepools ist in einem Stapel geordnet. Die neuesten Autofreigabepools werden zu der Oberseite des Stapels hinzugefügt und ausgehend von dort aufgerufen. Zugriff auf den Stapel wird über eine "globale Unterroutine" durchgeführt. Im Allgemeinen kann jegliches Stück Kode das Autofreigabeobjekt erzeugen. Bei einer bevorzugten Ausführungsform ist ein Kode, der eine Eingabe von Benutzern oder von anderen Computern in einem Netzwerk behandelt (in dieser Anmeldung auch ein "Eingabemanagement-Code" genannt), für eine Erzeugung des Autofreigabepools verantwort. Der Eingabemanagement-Code detektiert Ereignisse, die angeben, dass ein neuer Arbeitszyklus anfangen muss (Beispiele solcher Ereignisse sind oben angegeben worden). Der Eingabemanagement-Code weist eine "While-Schleife" auf, die kontinuierlich eine Aktivität überprüft, die den Beginn eines neuen Arbeitszyklus angibt. Wenn der Eingabemanagement-Code eine einen Arbeitszyklus auslösende Aktivität detektiert, erzeugt der Kode einen Autofreigabepool und wartet auf das Ende des Arbeitszyklus. Am Ende des Arbeitszyklus entfernt der Eingabemanagement-Code den Autofreigabepool, der als Ergebnis dieses Arbeitszyklus erzeugt wurde. Der Eingabemanagement-Code eines beliebigen Programmteils, der einen neuen Autofreigabepool erzeugen möchte, würde diese globale Unterroutine aufrufen, die für den anfragenden Programmteil einen neuen Autofreigabepool erzeugt. Sobald ein neuer Autofreigabepool für den anfragenden Programmteil erzeugt ist, wird eine als "füge Objekt hinzu" bezeichnete Nachricht aufgerufen, um Objekte zur Verwendung in diesem Arbeitszyklus zu registrieren.
Ein weiterer Weg, auf dem der Eingabemanagement-Code einen Autofreigabepool verwenden kann, besteht darin, zu veranlassen, dass ein Objekt, das aufgrund des neuen Arbeitszyklus erzeugt wurde (mit anderen Worten das Objekt, das am Ende des Arbeitszyklus freizugeben ist), eine "Autofreigabe-Unterroutine" aufruft. Indem diese Unterroutine aufgerufen wird, behält der Autofreigabepool an der Oberseite des Autofreigabepoolstapels das aufgrund des neuen Arbeitszyklus aufgerufene Objekt bei (und gibt es später frei). Als Beispiel wird angenommen, dass in dem Fall, der oben hinsichtlich einer Wiedergabe eines Pop-Up-Menüs in einem Fenster diskutiert wurde, ein Objekt "Pop-Up" als Ergebnis des neuen Arbeitszyklus erzeugt wird. Es wird daran erinnert, dass der neue Arbeitszyklus von dem Eingabemanagement-Code in Antwort auf die Benutzereingabe, zum Beispiel ein Maus-Druck, detektiert wird. Es ist dann erwünscht, dass der neue Autofreigabepool einen Zeiger auf dieses Objekt speichert. Der folgende objektive C-Code ist ein Beispiel, wie dies erreicht werden kann.
Wie zuvor wird am Ende des Arbeitszyklus, der durch den Maus-Druck ausgelöst wurde, der Autofreigabepool entfernt, der ein Verweis zu dem Popup-Objekt speichert.
Die Erfindung befreit einen Programmierer von der ermüdenden und fehleranfälligen Forderung der bekannten Technik, zu überwachen, ob einem Zielobjekt zugewiesener Speicherplatz erneut nutzbar gemacht (d. h. freigegeben) werden muss, wenn die das Zielobjekt aufrufende Unterroutine dieses Objekt nicht länger benötigt. Man betrachte ein Beispiel der Anwendung unserer Erfindung bei einem Fall, der verknüpfte Arbeitszyklen umfasst. Man nehme an, dass während eines übergeordneten Arbeitszyklus, der eine Wiedergabe eines Fensters auf einen Bildschirm umfasst, ein untergeordneter Arbeitszyklus aus einem Maus-Druck besteht, um ein Paneel in dem aktuellen Fenster zu öffnen. Das Paneel kann jedoch aufgrund einer anderen Aktivität bereits offen sein, die über den Arbeitszyklus des Maus-Drucks hinaus dauern würde. In diesem Fall muss ein Programmierer der bekannten Technik überwachen, ob das Paneel bereits offen war und diesen Fall von einem Fall unterscheiden, in dem das Paneel nicht bereits offen ist. Im vorherigen Fall muss der Programmierer gewährleisten, dass der dem Paneel zugewiesene Speicherplatz am Ende des Arbeitszyklus des Maus-Drucks nicht wieder nutzbar gemacht wird. Im letzteren Fall muss der Programmierer den dem Paneel zugewiesener Speicherplatz erneut nutzbar machen, weil das Paneel nicht länger benötigt wird. Wenn die Anzahl verknüpfter übergeordneter und untergeordneter Arbeitszyklen ansteigt, muss der Programmierer der bekannten Technik eine ansteigende Anzahl von Möglichkeiten überwachen.
Unsere Erfindung hat diese Schwierigkeiten überwunden. Gemäß unserer Erfindung wird ein Verweis auf das Zielobjekt, in diesem Fall das Objekt "offenes Paneel", von dem Autofreigabepool gespeichert. Der Autofreigabepool wird am Anfang des Arbeitszyklus des Maus-Drucks erzeugt und am Ende dieses Arbeitszyklus entfernt. Wenn kein Paneel bereits offen ist, wird daher die Referenzzählung des Objekts offenes Paneel am Ende des Arbeitszyklus des Maus-Drucks auf Null verringert, weil der Autofreigabepool entfernt wurde. Am Ende des Arbeitszyklus des Maus-Drucks wird dem entsprechend der Speicherplatz, der dem Objekt offenes Paneel zugewiesen wurde, transparent für den Programmierer erneut nutzbar gemacht. Wenn jedoch ein Fensterpaneel bereits offen ist und über die Dauer des Arbeitszyklus des Maus-Drucks hinaus offen bleiben soll, führt die Entfernung des Autofreigabepools nicht zu einer Verringerung der Referenzzählung des Objekts offenes Paneel auf Null. Die Referenzzählung des Objekts offenes Paneel bleibt größer als Null, weil ein Objekt, zusätzlich zu dem Autofreigabepool, das Objekt offenes Paneel beibehalten hat. Dem entsprechend wird am Ende des Arbeitszyklus des Maus-Drucks der Speicherplatz, der dem Objekt offenes Paneel zugewiesen wurde, nicht erneut nutzbar gemacht. Dies wird ebenfalls transparent für den Programmierer erreicht.

Daher wurde ein transparentes lokales und verteiltes Speichermanagementsystem beschrieben. Fig. 1

Videoverstärker	VIDEO AMP
Videomultiplexer-Schieber	VIDEO MUX AND SHIFTERS
Videospeicher	VIDEO MEMORY
Hauptspeicher	MAIN MEMORY
Tastatur	KEYBOARD
Maus	MOUSE
Massenspeicher	MASS STORAGE

Fig. 3

transienter Speicher	TRANSIENT MEMORY
dauerhafter Speicher	PERSISTENT MEMORY
Mausereignis	MOUSE EVENT
Hauptfenster	MAIN WINDOW
Unterfenster	SUB WINDOW

Fig. 2A

Warte auf Arbeitszyklus	WAIT FOR DUTY CYCLE
auslösendes Ereignis	TRIGGERING EVENT
Anfang eines neuen	BEGINNING OF NEW
Arbeitszyklus?	DUTY CYCLE?
Erzeuge neuen	CREATE NEW AUTO
Autofreigabepool	RELEASE POOL
Erzeuge Zielobjekt in	CREATE TARGET OBJECT
Antwort auf das Ereignis,	IN RESPONSE TO THE
das den neuen Arbeitszyklus	EVENT THAT TRIGGERED
ausgelöst hat	THE NEW DUTY CYCLE
Weise Speicher dem	ALLOCATE MEMORY TO
Zielobjekt zu	TARGET OBJECT
Behalte das Zielobjekt	RETAIN THE TARGET
durch den Autofreigabepool	OBJECT BY THE AUTO
bei	RELEASE POOL
Erhöhe Referenzzählung	INCREASE REFERENCE COUNT
des Zielobjekts um die	OF TARGET OBJECT EQUAL
gleiche Anzahl von	BY THE NUMBER OF OBJECTS
Objekten, die derzeit	CURRENTLY RETAINING TARGET
das Zielobjekt beibehalten	OBJECT
Nein	NO
Ja	YES

Fig. 2B

Ende des neuen Arbeitszyklus?	END OF THE NEW DUTY CYCLE?
Entferne den Autofreigabepool	DISPOSE OF THE AUTO
	RELEASE POOL
Verringere Referenzzählung	DECREMENT REFERENCE COUNT
des Zielobjekts um die	OF TARGET OBJECT BY THE
Anzahl von Objekten, die	NUMBER OF OBJECTS RELEASING
das Zielobjekt freigeben	THE TARGET OBJECT
Ist Referenzzählung des	TARGET OBJECT REFERENCE
Zielobjekts gleich Null?	COUNT IS EQUAL TO ZERO?
Gib dem Zielobjekt zugewiesenen	DEALLOCATE MEMORY
Speicher frei	ALLOCATED TO TARGET OBJECT
Nein	NO
Ja	YES

Fig. 4 und Fig. 5

transienter Speicher	TRANSIENT MEMORY
dauerhafter Speicher	PERSISTENT MEMORY
Unterfenster	SUB WINDOW
Hauptfenster	MAIN WINDOW
Pop-Up-Menü	POPUP MENU

Fig. 6

Programmteil A	TASK A
Lokale Vorrichtung	LOCAL MACHINE
Daten von Interesse	DATA OF INTEREST
für Programmteil B	TO TASK B
Programmteil B	TASK B
Entfernte Vorrichtung	REMOTE MACHINE
Proxy von Programmteil A	TASK A's PROXY
Netzwerkkommunikations-	NETWORK COMMUNICATION
Verbindung	LINK

Fig. 7A

Lokale Vorrichtung	LOCAL MACHINE
Programmteil A	TASK A
Proxy für Programmteil B	PROXY TO TASK B
Entfernte Vorrichtung	REMOTE MACHINE
Programmteil B	TASK B

Fig. 7B, 7C, 7D und 7E

Lokale Vorrichtung	LOCAL MACHINE
Programmteil A	TASK A
Netzwerknachricht	NETWORK MESSAGE
Proxy für Programmteil B	PROXY TO TASK B
Entfernte Vorrichtung	REMOTE MACHINE
Programmteil B	TASK B

Fig. 8

Autofreigabepool	AUTO RELEASE POOL
Zeiger auf A	POINTER TO A
Zeiger auf B	POINTER TO B
Zeiger auf C	POINTER TO C
Referenzzählung	REF COUNT
Objekt	OBJECT

Claims

Speichermanagementverfahren, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: Erzeugen (105) eines Autofreigabepools (221) am Anfang eines Arbeitszyklus einer Anwendung, wobei ein Arbeitszyklus eine Periode einer Aktivität eines Anwendungsprogramms definiert, wobei der Autofreigabepool einen oder mehrere Zeiger (223, 225, 227) zu einem oder mehreren zugewiesenen Speicherplätzen (229, 235, 241) umfasst; Zuordnen (113) einer Referenzzählung (231, 237, 243) zu jedem des einen oder mehreren zugewiesenen Speicherplätzen (229, 235, 243), wobei die Referenzzählung einen Wert aufweist, der der Anzahl an Programmen entspricht, die den entsprechenden zugewiesenen Speicherplatz beibehalten, wobei jede Referenzzählung für den Autofreigabepool als eine Referenz (233, 239, 245) für einen entsprechenden Speicherplatz (229, 235, 241) Rechnung trägt; Freigeben (117) des Autofreigabepools am Ende des Arbeitszyklus; und Freigeben (123) jedes des einen oder mehreren zugewiesenen Speicherplätze (229, 235, 241), wenn die entsprechende Referenzzählung (231, 237, 243) für jeden zugewiesenen Speicherplatz Null erreicht.
Verfahren nach Anspruch 1, bei dem der eine oder die mehreren zugewiesenen Speicherplätze ein Objekt in einer objektorientierten Umgebung umfassen.
Verfahren nach Anspruch 1 oder 2, bei dem der eine oder die mehreren zugewiesenen Speicherplätze einen Block Computerkode umfassen.
Verfahren nach Anspruch 1, 2 oder 3, bei dem der eine oder die mehreren zugewiesenen Speicherplätze einen Block an Daten umfassen.
Verfahren nach Anspruch 1, 2, 3 oder 4, bei dem der Autofreigabepool ein Autofreigabeobjekt umfasst.
Verfahren nach Anspruch 1, 2, 3, 4 oder 5, bei dem das Erzeugen des Autofreigabepools an dem Beginn eines Arbeitszyklus umfasst: Detektieren (103) der Einleitung einer Unterroutine.
Verfahren nach Anspruch 1, 2, 3, 4 oder 5, bei das Erzeugen des Autofreigabepools an dem Beginn eines Arbeitszyklus umfasst: Detektieren (103) eines Verfahrensaufrufs.
Verfahren nach Anspruch 1, 2, 3, 4, 5, 6 oder 7, bei dem der Arbeitszyklus ausgehend von einem entfernten Prozess (257) eingeleitet wird.
Verfahren nach Anspruch 1, 2, 3, 4, 5, 6, 7 oder 8, bei dem der eine oder die mehreren zugewiesenen Speicherplätze ein oder mehrere Programmelemente umfassen, die ausgehend von einem entfernten Prozess kopiert werden.
Verfahren nach Anspruch 1, 2, 3, 4,5, 6, 7, 8 oder 9, bei dem der eine oder die mehreren zugewiesenen Speicherplätze einen oder mehrere Proxy (265) zu einem oder mehreren entfernten Objekten umfassen.
Verfahren nach Anspruch 1, 2, 3, 4, 5, 6, 7, 8, 9 oder 10, bei dem eine Mehrzahl an Arbeitszyklen verschachtelt sind, wobei das Verfahren ferner umfasst: Stapeln des Autofreigabepools auf einen oder mehrere zuvor vorhandene Autofreigabepools.
Computerprogrammprodukt mit darin verkörpertem computerlesbarem Kode, um einen Computer zu veranlassen, das Verfahren nach Anspruch 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 oder 11 durchzuführen.
Speichermanagementvorrichtung zur Verwendung in einem Computer, der eine Anwendung mit einem oder mehreren Arbeitszyklen ausführt, wobei die Vorrichtung dadurch gekennzeichnet ist, dass sie umfasst: eine Einrichtung zum Erzeugen eines Autofreigabepools (221), der einem Arbeitszyklus einer Anwendung zugeordnet ist, wobei ein Arbeitszyklus eine Periode einer Aktivität eines Anwendungsprogramms definiert, wobei der Autofreigabepool einen oder mehrere Pointer (223, 225, 227) zu einem oder mehreren zugewiesenen Speicherplätzen (229, 235, 241) umfasst; eine Einrichtung zum jeweiligen Zuordnen (113) einer Referenzzählung (231, 237, 243) zu dem einen oder den mehreren zugewiesenen Speicherplätzen (229, 235, 243), wobei die Referenzzählung einen Wert aufweist, der der Anzahl an Programmen entspricht, die den entsprechenden zugewiesenen Speicherplatz beibehalten, wobei jede Referenzzählung für den Autofreigabepool als eine Referenz (233, 239, 245) für einen entsprechenden Speicherplatz (229, 235, 241) Rechnung trägt; eine Speichermanagementeinrichtung, die konfiguriert ist, den Autofreigabepool (221) an dem Anfang des Arbeitszyklus (105) zu erzeugen und den Autofreigabepool an dem Ende des Arbeitszyklus (117) freizugeben, wobei die Speichermanagementeinrichtung ferner kon figuriert ist, jeden des einen oder der mehreren zugewiesenen Speicherplätze freizugeben, wenn jede entsprechende Referenzzählung Null erreicht.
Speichermanagementvorrichtung nach Anspruch 13, bei dem der Autofreigabepool ein Autofreigabeobjekt in einer objektorientierten Umgebung umfasst.
Speichermanagementvorrichtung nach Anspruch 13 oder 14, bei dem die Speichermanagementeinrichtung ferner konfiguriert ist, ein Ereignis zu detektieren, das den Arbeitszyklus (103) einleitet.
Speichermanagementvorrichtung nach Anspruch 13, 14 oder 15, bei der der Speichermanager ferner konfiguriert ist, ein Ereignis zu detektieren, das den Arbeitszyklus (115) beendet.
Speichermanagementvorrichtung nach Anspruch 13, 14, 15 oder 16, bei der der Arbeitszyklus einer Unterroutine der Anwendung zugeordnet ist.
Speichermanagementvorrichtung nach Anspruch 13, 14, 15, 16 oder 17, bei der die Anwendung eine Mehrzahl von verschachtelten Arbeitszyklen umfasst und wobei die Vorrichtung umfasst: eine Mehrzahl von Autofreigabepools, die jeweils der Mehrzahl an verschachtelten Arbeitszyklen zugeordnet sind, wobei die Mehrzahl an Autofreigabepools in einem Stapel gespeichert sind.