DE60318993T2 - Eingebettete Speicherbereinigung - Google Patents

Eingebettete Speicherbereinigung Download PDF

Info

Publication number
DE60318993T2
DE60318993T2 DE60318993T DE60318993T DE60318993T2 DE 60318993 T2 DE60318993 T2 DE 60318993T2 DE 60318993 T DE60318993 T DE 60318993T DE 60318993 T DE60318993 T DE 60318993T DE 60318993 T2 DE60318993 T2 DE 60318993T2
Authority
DE
Germany
Prior art keywords
objects
root
garbage collection
context
embedded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60318993T
Other languages
English (en)
Other versions
DE60318993D1 (de
Inventor
Gerard Chauvel
Serge Lassere
Dominique D'inverno
Maija Kuusela
Gilbert Cabillic
Jean-Philippe Lesot
Michel Banâtre
Jean-Paul Routeau
Salam Majoul
Frederic Parain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Texas Instruments Inc
Original Assignee
Texas Instruments Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Texas Instruments Inc filed Critical Texas Instruments Inc
Application granted granted Critical
Publication of DE60318993D1 publication Critical patent/DE60318993D1/de
Publication of DE60318993T2 publication Critical patent/DE60318993T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0269Incremental or concurrent garbage collection, e.g. in real-time systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99956File allocation
    • Y10S707/99957Garbage collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Memory System (AREA)

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich allgemein auf Prozessoren und insbesondere auf das den Prozessoren zugeordnete Speichermanagement.
  • HINTERGRUNDINFORMATIONEN
  • Viele Typen von elektronischen Vorrichtungen sind batteriebetrieben und verbrauchen somit vorzugsweise so wenig Energie wie möglich. Ein Beispiel ist ein Mobilfunktelephon. Ferner kann es wünschenswert sein, verschiedene Typen von Multimediafunktionalität in einer elektronischen Vorrichtung wie etwa einem Mobiltelephon zu implementieren. Beispiele einer Multimediafunktionalität können, ohne eine Einschränkung zu treffen, Spiele, Audio-Decoder, Digitalkameras usw. umfassen. Es ist somit wünschenswert, eine solche Funktionalität in einer Weise in einer elektronischen Vorrichtung zu implementieren, dass alles Sonstige gleich bleibt, die schnell ist, so wenig Energie wie möglich verbraucht und so wenig Speicher wie möglich benötigt. Verbesserungen in diesem Bereich sind wünschenswert.
  • Die US-Patentanmeldung Nr. 2006/0069905 beschreibt ein Verfahren und ein System für gleichzeitige Datenmüllsammlung, wobei lebendige Speicherobjekte, d. h. solche, die kein Datenmüll sind, markiert werden kann, während eine Anwendung abläuft.
  • KURZZUSAMMENFASSUNG
  • In einigen Ausführungsformen umfasst ein elektronisches System einen Prozessor, einen mit dem Prozessor gekoppelten Speicher und eine Anwendungsprogrammierungsschnittstelle, die veranlasst, dass ein eingebettetes Datenmüllsammelobjekt aktiv wird. Der Speicher speichert ein oder mehrere Objekte, die wahlweise Bezugnahmen von Wurzelobjekten haben. Das eingebettete Datenmüllsammelobjekt verwendet vorzugsweise Steuerdaten, um zu veranlassen, dass Objekte aus dem Speicher entfernt werden, wobei die entfernten Objekte jene Objekte umfassen, die erzeugt wurden, während ein eingebettetes Daten müllsammelobjekt aktiv war, und die keine Bezugnahmen von Wurzelobjekten haben.
  • In anderen Ausführungsformen umfasst ein Verfahren das Starten eines eingebetteten Datenmüllsammlers, das Auswählen eines aus dem Speicher zu entfernenden Objekts, wobei der Speicher Wurzelobjekte enthält, die wahlweise Bezugnahmen auf zugeordnete Objekte haben können, und das Entfernen des ausgewählten Objekts. Das Auswählen des zu entfernenden Objekts umfasst das Identifizieren von Wurzelobjekten, deren Kontext sich geändert hat, und das Verfolgen der identifizierten Wurzelobjekte zu Objekten, auf die Bezug genommen wird, um zu bestimmen, welche Objekte einem Wurzelobjekt, dessen Kontext sich geändert hat, zugeordnet sind. Das Entfernen des ausgewählten Objekts umfasst das Entfernen eines Objekts, das erzeugt wurde, während der eingebettete Datenmüllsammler aktiv war, und das nicht als ein Wurzelobjekt, dessen Kontext sich geändert hat, bestimmt worden ist.
  • SCHREIBWEISE UND TERMINOLOGIE
  • In der gesamten folgenden Beschreibung und in den Ansprüchen werden gewisse Begriffe verwendet, um auf besondere Systemkomponenten zu verweisen. Wie ein Fachmann erkennen wird, können Halbleiterfirmen einer Komponente verschiedene Namen zuordnen. Dieses Dokument beabsichtigt nicht, zwischen Komponenten, die sich im Namen, jedoch nicht in der Funktion unterscheiden, einen Unterschied zu machen. In der folgenden Besprechung und in den Ansprüchen werden die Begriffe "enthalten" und "umfassen" in einem erweiterten Sinn verwendet und sollten somit so interpretiert werden, dass sie "enthalten, jedoch nicht darauf begrenzt sein" bedeuten. Außerdem ist der Begriff "koppeln" oder "koppelt" so auszulegen, dass er sowohl eine indirekte als auch eine direkte Verbindung bedeutet. Wenn eine erste Vorrichtung an eine zweite Vorrichtung gekoppelt ist, kann diese Verbindung somit durch eine direkte Verbindung oder durch eine indirekte Verbindung über andere Vorrichtungen und Verbindungen eingerichtet sein.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • Für eine ausführlichere Beschreibung der bevorzugten Ausführungsformen der vorliegenden Erfindung wird nun Bezug auf die begleitende Zeichnung genommen, worin:
  • 1 einen Blockschaltplan eines beispielhaften Haufens (heap) in einem elektronischen System zeigt;
  • 2 ein Diagramm eines Systems gemäß bevorzugten Ausführungsformen der Erfindung, das eine Java-Stapelspeichermaschine bzw. einen Java-Kellerspeicherautomaten (JSM) und eine Hauptprozessoreinheit (MPU) umfasst, zeigt;
  • 3 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung, der Datenstrukturen enthält, zeigt;
  • 4 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung während der ersten Stufe der Datenmüllausführung zeigt;
  • 5 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung während der zweiten Stufe der Datenmüllausführung zeigt;
  • 6 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung während der dritten Stufe der Datenmüllausführung zeigt;
  • 7 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung während der vierten Stufe der Datenmüllausführung zeigt; und
  • 8 einen Blockschaltplan eines Haufens gemäß einer bevorzugten Ausführungsform der Erfindung während der fünften Stufe der Datenmüllausführung zeigt.
  • GENAUE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Die folgende Besprechung ist auf verschiedene Ausführungsformen der Erfindung gerichtet. Obwohl eine oder mehrere dieser Ausführungsformen bevor zugt sein können, sollten die offenbarten Ausführungsformen nicht so interpretiert oder anderweitig gebraucht werden, als würden sie den Umfang der Offenbarung, die die Ansprüche umfasst, begrenzen, sofern dies nicht anderweitig spezifiziert ist. Außerdem wird ein Fachmann verstehen, dass die folgende Beschreibung eine breite Anwendung hat und dass die Besprechung irgendeiner Ausführungsform nur als beispielhaft für jene Ausführungsform gemeint ist und nicht so auszulegen ist, als würde sie den Umfang der Offenbarung, die die Ansprüche umfasst, auf jene Ausführungsform begrenzen.
  • Der hier offenbarte Gegenstand ist auf eine programmierbare elektronische Vorrichtung wie etwa einen Prozessor, der einen Speicher besitzt, in dem Computerprogramme gespeichert werden können, die einer stapelspeicher- bzw. kellerspeicherbasierten Sprache (z. B. Java) zugeordnet sind, gerichtet. Die Computerprogramme können durch eine "virtuelle" Maschine ausgeführt werden, die in Form von Hardware, Software oder sowohl Hardware als auch Software implementiert sein kann. Die virtuelle Maschine kann das Computerprogramm in Maschinencode (z. B. Java-Bytecodes) transformieren, die fundamentale Computeroperationen in einem Abschnitt des Speichers, der als "Stapelspeicher" bzw. "Kellerspeicher" bezeichnet wird, ausführen können. Die Java-Bytecodes können während ihrer Ausführung durch die virtuelle Maschine den Stapelspeicher verwenden, um Zwischenwerte zu speichern.
  • Neben dem Stapelspeicher kann ein Speicherabschnitt für das Speichern von Java-Objekten (z. B. Variablen, Klassen, Typen) reserviert sein. Dieser Speicherabschnitt kann als "Haufen" (Heap) bezeichnet werden. Wenn ein Java-Objekt erzeugt wird, belegt das Objekt Speicher in dem Haufen. Die Größe des in dem Haufen belegten Speichers kann von dem Typ (z. B. int, Jong, array) der in dem erzeugten Objekt enthaltenen Java-Felder abhängen. Eine virtuelle Maschine kann in Abhängigkeit von dem Prozentsatz der Verwendung des Haufens die Menge an reserviertem Speicher für den Haufen einstellen. Wenn beispielsweise der Haufen übermäßig verwendet wird, reserviert die virtuelle Maschine zusätzlichen Speicher für den Haufen.
  • In dem Haufen gespeicherte Objekte können durch einen Mechanismus, der als "Bezugnahme" (reference) bezeichnet wird, andere in dem Haufen gespeicherte Objekte verwenden. Beispielsweise kann ein erstes Objekt eine Variable verwenden, die einem zweiten Objekt zugeordnet ist. Das erste Objekt kann, sobald es in den Haufen geladen ist, eine Bezugnahme zu dem zweiten Objekt erzeugen. Sobald die Bezugnahme zwischen den Objekten erzeugt worden ist, kann das erste Objekt auf die dem zweiten Objekt zugeordnete Variable zugreifen. Eine Menge aller Bezugnahmen, die einem Objekt zugeordnet ist, wird als "Kontext" für jenes Objekt bezeichnet. Bezugnahmen werden durch eine "PutRef"-Operation, die all jenen Java-Bytecodes, die ein Schreiben (Write) auf ein Bezugnahmefeld oder ein Array-Element ausführen, entspricht, eingeführt und modifiziert. Als solches kann sich der Kontext eines Java-Objekts nur dann ändern, wenn eine PutRef-Operation auf das Objekt ausgegeben wird.
  • Die Größe des Haufens kann durch die Gesamtmenge an einem System zugeordnetem Speicher begrenzt sein. Sobald der Haufen diese Maximalgröße erreicht und voll genutzt wird, können keine weiteren Objekte erzeugt werden. Sobald dieser Zustand eintritt, werden gegenwärtig in dem Haufen gespeicherte Objekte, die nicht mehr benötigt werden, durch einen Java-Prozess aus dem Haufen herausgenommen, um Raum für andere Objekte zu schaffen. Der Java-Prozess, der für das Entfernen von Objekten aus dem Haufen verantwortlich ist, kann als "Datenmüllsammelprozess" bezeichnet werden. Datenmüll repräsentiert jene Objekte, die ein Datenmüllsammelprozess auswählt, um sie auf Dauer aus dem Haufen zu entfernen. Nachdem ein Datenmüllsammelprozess Objekte auf Dauer aus dem Haufen entfernt hat, kann diesen Objekten zugeordneter Speicher anderen Objekten zugewiesen werden. Ein Datenmüllsammelprozess verwendet "Wurzeln", um Objekte zu identifizieren, die auf Dauer aus dem Haufen entfernt werden können. Obwohl der Anwender Wurzeln zuteilen kann, werden Wurzeln im Allgemeinen durch das zugrunde liegende Objektlaufzeitprogramm automatisch zugeteilt. Dieses Objektlaufzeitprogramm erzeugt die ersten Objekte der Anwendung als Objekte, die von der Anwendung selbst nicht notwendigerweise betrachtet werden müssen, oder erzeugt Stapelspeicher (Speicherblöcke), die Bezugnahmen auf Objekte enthalten und diesen Objekten als Wurzeln zugeteilt sind.
  • Nachdem Wurzeln identifiziert und zugeteilt sind, kann ein Datenmüllsammelprozess Bezugnahmen von den Wurzeln zu anderen Objekten untersuchen. Beispielsweise zeigt 1 einen beispielhaften Haufen 100, der Wurzeln 102 und Objekte 104, 106, 108 und 110 enthält. Obwohl dies nicht explizit gezeigt ist, können die Wurzeln 102 irgendwelche in dem Haufen gespeicherte Objekte umfassen, die durch einen Datenmüllsammelprozess als Wurzeln zugeteilt worden sind. Die Wurzeln 102 können durch die Bezugnahme 112 direkt auf das Objekt 104 Bezug nehmen. Das Objekt 104 kann ferner durch die Bezugnahme 114 auf das Objekt 106 Bezug nehmen. Wenn ein Datenmüllsammelprozess an dem Haufen 100 abläuft, können durch eine Prozedur innerhalb des Datenmüllsammelprozesses alle Bezugnahmen von dem Wurzelobjekt 102 ausgehend verfolgt werden. Die Prozedur des Verfolgens von Bezugnahmen von einem Wurzelobjekt zu anderen in einem Haufen gespeicherten Objekten kann als "Verfolgungsroutine" bezeichnet werden. Beispielsweise kann eine Verfolgungsroutine an dem Haufen 100 die Java-Objekte 104 und 106 als für die Wurzeln 102 zugänglich identifiziert werden. Anhand der während der Verfolgungsroutine identifizierten Objekte kann ein Datenmüllsammelprozess bestimmen, welche Objekte aus dem Haufen zu entfernen sind. Bei der Verfolgungsroutine identifizierte Objekte werden typischerweise nicht entfernt; bei der Verfolgungsroutine nicht identifizierte Objekte werden entfernt. Da die Verfolgungsroutine bei den Wurzeln beginnt, werden identifizierte Objekte von den Wurzeln aus "erreichbare" Objekte genannt und nicht identifizierte Objekte "unerreichbare" Objekte genannt. Das Grundprinzip hinter dieser Entfernungstechnik betrachtet bei der Verfolgungsroutine nicht identifizierte Objekte als für die ablaufende Anwendung nicht notwendig, weshalb sie entfernt werden können. In dem Beispiel von 1 haben die Objekte 108 und 110 keine Bezugnahmen und werden somit bei der Verfolgungsroutine an dem Haufen 100 nicht identifiziert. Als solches kann der Datenmüllsammelprozess diese Objekte aus dem Haufen entfernen. Die bevorzugte Ausführungsform der Erfindung kann Datenmüllsammler wie etwa jenen, der oben beschrieben worden ist, mit einem bevorzugten Datenmüllsammler, der weiter unten beschrieben wird, kombinieren.
  • Das Folgende beschreibt die Funktionsweise der bevorzugten Ausführungsform eines Systems, bei dem ein Datenmüllsammelprozess Objekte aus dem Haufen entfernen kann, nachdem die Objekte durch eine Maschine (z. B. einen Prozessor, eine virtuelle Maschine) verwendet worden sind. Es können weitere Prozessorarchitekturen und Ausführungsformen verwendet werden, womit diese Offenbarung und die Ansprüche, die folgen, nicht auf irgendeinen bestimmten Typ von Prozessor begrenzt sind. Einzelheiten hinsichtlich des Datenmüllsam melprozesses folgen auf die Beschreibung des Prozessors und der virtuellen Maschine.
  • Der hier beschriebene Prozessor ist für das Ausführen von JavaTM-Bytecodes oder eines vergleichbaren Codes besonders geeignet, Wie wohlbekannt ist, ist Java für eingebettete Anwendungen besonders geeignet. Java ist eine relativ "dichte" Sprache, was bedeutet, dass, verglichen mit verschiedenen anderen Programmiersprachen, jeder Befehl im Mittel eine große Anzahl von Funktionen ausführen kann. Die dichte Natur von Java ist für tragbare, batteriebetriebene Vorrichtungen, die vorzugsweise so wenig Speicher wie möglich enthalten, um Raum und Energie zu sparen, von besonderem Nutzen. Der Grund für das Ausführen von Java-Code ist jedoch nicht Stoff dieser Offenbarung oder der Ansprüche, die folgen.
  • In 2 ist nun ein System 200 gemäß einer bevorzugten Ausführungsform der Erfindung gezeigt. Wie gezeigt ist, umfasst das System wenigstens zwei Prozessoren 202 und 204. Der Prozessor 202 wird zum Zweck dieser Offenbarung als Java-Stapelspeichermaschine (JSM) bezeichnet, während der Prozessor 204 als Hauptprozessoreinheit (MPU) bezeichnet wird. Das System kann außerdem einen Speicher 206 umfassen, der sowohl mit der JSM 202 als auch mit der MPU 204 gekoppelt ist und somit für beide Prozessoren zugänglich ist. Wenigstens ein Abschnitt des Speichers 206 kann beiden Prozessoren gemeinsam sein, was bedeutet, dass beide Prozessoren auf dieselben gemeinsamen Speicherorte zugreifen können. Ferner kann nach Bedarf ein Abschnitt des Speichers 206 als privat für den einen oder den anderen der Prozessoren benannt sein. Das System 200 kann außerdem eine virtuelle Java-Maschine (JVM) 208, einen Compiler 210 und eine Anzeigevorrichtung 214 umfassen. Die JSM 202 enthält vorzugsweise eine Schnittstelle zu einer oder mehreren Eingabe/Ausgabe-(E/A)-Vorrichtungen wie etwa einem Tastenblock, um einem Anwender das Steuern verschiedener Aspekte des Systems 200 zu ermöglichen. Außerdem können Datenströme von dem E/A-Raum in die JSM 202 empfangen werden, um durch die JSM 202 verarbeitet zu werden. Nach Bedarf können weitere (nicht spezifisch gezeigte) Komponenten aufgenommen sein.
  • Um auf 2 weiter Bezug zu nehmen, kann Java-Code, wie allgemein bekannt ist, eine Vielzahl von "Bytecodes" 212 umfassen. Die Bytecodes 212 kön nen der JVM 208 bereitgestellt, durch den Compiler 210 kompiliert und der JSM 202 und/oder der MPU 204 zur Ausführung darin bereitgestellt werden. Gemäß einer bevorzugten Ausführungsform der Erfindung kann die JSM 202 wenigstens einen Teil und im Allgemeinen den größten Teil der Java-Bytecodes ausführen. Jedoch kann, wenn es passend ist, die JSM 202 die MPU 204 auffordern, einen oder mehrere von der JSM 202 nicht ausgeführte oder nicht ausführbaren Java-Bytecodes auszuführen. Neben dem Ausführen von Java-Bytecodes kann die MPU 204 auch Nicht-Java-Befehle ausführen. Die MPU 204 beherbergt außerdem ein (nicht spezifisch gezeigtes) Betriebssystem (O/S), das verschiedene Funktionen, die das System-Speichermanagement, das System-Taskmanagements, das der JVM 208 und den meisten oder den gesamten anderen nativen Tasks, die auf dem System ablaufen, Rechenzeit zuteilt, das Management der Anzeigevorrichtung 214, das Empfangen einer Eingabe von Eingabevorrichtungen usw. umfassen, ausführt. Ohne eine Einschränkung zu treffen, kann Java-Code verwendet werden, um irgendeine aus einer Vielzahl von Anwendungen, die Multimedia, Spiel oder Web-basierte Anwendungen umfassen, in dem System 200 auszuführen, wohingegen Nicht-Java-Code, der das O/S und andere native Anwendungen umfassen kann, auf der MPU 204 in dem System ablaufen kann.
  • Die JVM 208 umfasst im Allgemeinen eine Kombination aus Software und Hardware. Die Software kann den Compiler 210 umfassen, während die Hardware die JSM 202 umfassen kann. Die JVM kann einen Klassenlader, einen Bytecodeverifizierer, einen allgemeinen Datenmüllsammler, der von dem hier beschriebenen bevorzugten Datenmüllsammler funktional getrennt sein kann, und eine Bytecodeinterpreterschleife, um jene Bytecodes, die von dem JSM-Prozessor 202 nicht ausgeführt werden, zu interpretieren, umfassen.
  • Gemäß bevorzugten Ausführungsformen der Erfindung kann ein Datenmüllsammelprozess durch Verwendung einer Anwendungsprogrammierungsschnittstelle (API) in ein Computerprogramm eingebettet werden. Die API umfasst vorzugsweise eine Reihe von Funktionen, die Programmentwickler ausführen können, um die Datenmüllsammlung zu steuern. Da der Datenmüllsammelprozess in einem Programm instanziert ist, läuft der Prozess in demselben Speicher-Thread wie das Programm, das diesen Prozess ausführt, ab. Der eingebettete Datenmüllsammelprozess kann dadurch, dass er im selben Speicher-Thread abläuft, Objekte, die von einem bestimmten Programm verwendet werden, wirksam entfernen. Dieser eingebettete Datenmüllsammelprozess kann hier als eingebetteter Datenmüllsammler (EGO) bezeichnet werden.
  • Die API des eingebetteten Datenmüllsammlers (EGC-API) umfasst vorzugsweise drei Funktionen zum Steuern des Betriebs des EGC. Eine erste Funktion, die die Konstruktorfunktion eines EGC-Objekts ist, instanziert den EGC in dem Haufen und baut Datenstrukturen auf, die von dem EGC verwendet werden. Eine zweite Funktion, "egc.start()", setzt den EGC in einen "aktiven" Zustand. Eine dritte Funktion, "egc.stop()", führt vorzugsweise die Verfolgungsroutine aus, entfernt ausgewählte Objekte aus dem Haufen und beendet einen aktiven EGC. Der Zustand des EGC kann jederzeit, nachdem zu der Zeit, zu der die egc.stop()-Funktion ausgeführt worden ist, die egc.start()-Funktion ausgeführt worden ist, als aktiv betrachtet werden. Das egc.start(() und das egc.stop() liegen vorzugsweise in derselben Ebene des Verfahrensaufrufs zum Entfernen. Dies kann das Analysieren der Inhalte des zugeordneten Stapelspeicherrahmens (stack frame) für das Suchen nach Bezugnahmen erübrigen.
  • Der EGC betrachtet für das Entfernen vorzugsweise nur Objekte, die in dem Haufen erzeugt worden sind, während der EGC aktiv war. In Kombination mit dem EGC können weitere Datenmüllsammler wie etwa jener, der oben beschrieben worden ist, verwendet werden, um Objekte aus dem Haufen zu entfernen, die von dem EGC nicht berücksichtigt worden sind. Außerdem ermöglicht der EGC im Gegensatz zu dem automatischen Zuteilen der Wurzeln für die Verfolgungsroutine einem Programmentwickler das Spezifizieren der Wurzeln unter Verwendung der Konstruktorparameter des zugeordneten EGC.
  • Spezifizierte Wurzeln können in den EGC aufgenommen werden, indem eine Datenstruktur, die als "Wurzelanordnung" (root-array) bezeichnet wird, verwendet wird. In der Wurzelanordnung können Bezugnahmen auf Objekte, die die Wurzeln für die Verfolgungsroutine des EGC definieren, enthalten sein. Beispielsweise kann ein Entwickler eine Bezugnahme auf ein bestimmtes Objekt in der Wurzelanordnung aufnehmen. Während der Verfolgungsroutine können alle Bezugnahmen, die diesem Objekt zugeordnet sind, identifiziert werden. Die während der Verfolgungsroutine identifizierten Objekte werden vorzugsweise nicht durch den EGC entfernt. Andere Objekte, die bei der momentanen oder der ver gangenen Aktivierung erzeugt wurden, während der EGC aktiv war, und bei der Verfolgungsroutine nicht identifiziert wurden, werden vorzugsweise entfernt. Die Fähigkeit des EGC, eine Spezifikation von Wurzelobjekten zu ermöglichen, gewährt einem Programmentwickler eine bessere Steuerung bei dem Datenmüllsammelprozess als mit herkömmlichen Datenmüllsammlern.
  • 3 zeigt einen beispielhaften Haufen 350 zur Verwendung mit dem EGC. Obwohl eine Wurzelanordnung Bezugnahmen auf irgendeine Anzahl von Objekten enthalten kann, umfasst in dem Beispiel von 3 die Wurzelanordnung 300 Bezugnahmen auf drei Wurzelobjekte 302, 304 und 306. Jedes Wurzelobjekt umfasst vorzugsweise drei zugeordnete Datenvariablen. Die erste Datenvariable, die als "Erreich- bzw. Erreichbarkeitsmenge" (reachset) bezeichnet wird, kann verwendet werden, um Bezugnahmen auf Objekte, die während der Verfolgungsroutine des EGC identifiziert worden sind, zu platzieren. Diese Bezugnahmen können all jene in dem Haufen gespeicherten Objekte, auf die durch ein bestimmtes Wurzelobjekt Bezug genommen wird, umfassen. Somit entspricht die Erreichmenge-Variable der Wurzel dem Wurzelkontext. Die Wurzelobjekte 302, 304 und 306 können, wie gezeigt ist, die Erreichmengen 308, 310 und 312 umfassen.
  • Die zweite Datenvariable ist ein Zustandsbit, das jedem Wurzelobjekt zugeordnet werden kann, um anzugeben, ob der Kontext der Bezugnahmen, direkten oder transitiven Bezugnahmen, der dem Wurzelobjekt zugeordnet ist, modifiziert worden ist. Dieses Zustandsbit kann als "modifiziertes Bit" bzw. "modifiziert-Bit" bezeichnet werden. Beispielsweise können auf die Ausführung der egc.start()-Funktion hin die modifizierten Bits anfänglich auf falsch gesetzt werden. Wenn während des Aktivzustands des EGC eine von einem Objekt des momentanen Wurzelkontexts ausgehende Bezugnahme modifiziert, erzeugt oder gelöscht wird, wird das modifizierte Bit jenes Wurzelobjekts auf wahr gesetzt. Wie gezeigt ist, umfassen die Wurzelobjekte 302, 304 und 306 die modifizierten Bits 314, 316 bzw. 318.
  • Gemäß bevorzugten Ausführungsformen der Erfindung kann das modifizierte Bit durch die JVM 208 automatisch modifiziert werden. Jedes Mal, wenn eine Bezugnahme erzeugt oder modifiziert wird, wird ein "PutRef"-Befehl an einem Objekt an die JVM ausgegeben. Eine Modifikation des PutRef-Befehls wird vor zugsweise vorgenommen, um das modifizierte Bit eines Wurzelobjekts auf wahr zu setzen, wenn ein PutRef an einem Objekt ausgeführt wird, das sich innerhalb eines Wurzelkontexts befindet. Um zu ermitteln, ob sich ein Objekt innerhalb eines Wurzelkontexts befindet, wird eine nachstehend beschriebene dritte Variable verwendet, die als "Wurzelidentifikator" bezeichnet wird.
  • Schließlich ist die dritte Datenvariable in jedem Wurzelobjekt ein Wurzelidentifikator. Der Wurzelidentifikator speichert eine Bezugnahme auf das Wurzelobjekt. Dementsprechend enthalten die Wurzelobjekte 302, 304 und 306 die Wurzelidentifikatoren 360, 362 und 364.
  • Um weiter auf 3 Bezug zu nehmen, können in Kombination mit dem EGC zwei variable Anordnungen (arrays) verwendet werden. Die erste Anordnung 320, die als "Haufenmenge" (heapset) bezeichnet wird, wird vorzugsweise verwendet, um Bezugnahmen auf Objekte in dem Haufen zu speichern, die sich, bevor und nachdem der EGC aktiv ist, innerhalb eines EGC-Wurzelkontexts befinden. Beispielsweise kann die Haufenmenge 320 Objekte enthalten, die sich in dem Haufen befinden, bevor der EGC gestartet wird. Die zweite Anordnung 322, die als "temporäre Menge" (tempset) bezeichnet wird, wird vorzugsweise verwendet, um die Bezugnahmen von Objekten zu speichern, die in dem Haufen erzeugt werden, während der EGC aktiv ist. Der Haufen 350 kann außerdem die Haufenobjekte 324 umfassen. Obwohl sich zu einer gegebenen Zeit irgendeine Anzahl von Objekten in dem Haufen befinden kann, umfassen die Haufenobjekte 324 in dem Beispiel von 3, wie gezeigt ist, drei Objekte 326, 328, 330. Jedem Objekt 326, 328, 330 ist ein Wurzelidentifikator 332, 334 und 336 zugeordnet. Ähnlich wie der Wurzelidentifikator bei den Wurzelobjekten wird der Wurzelidentifikator auf null gesetzt, wenn das Objekt erzeugt wird. Der Wurzelidentifikator eines Haufenobjekts speichert vorzugsweise eine Bezugnahme auf das jenes Wurzelobjekt, das auf das Haufenobjekt Bezug nimmt. Beispielsweise kann ein Objekt erzeugt und in den Kontext eines Wurzelobjekts eingeführt werden, während der EGC aktiv ist. Der diesem neu erzeugten Objekt zugeordnete Wurzelidentifikator kann eine Bezugnahme auf jenes Wurzelobjekt enthalten, das auf das Objekt Bezug nimmt. Der EGC-Algorithmus ist damit beauftragt, während der Verfolgungsroutine den Wurzelidentifikator von Objekten in dem Haufen zu setzen, um zu erfassen, welche Wurzeln einen veränderten Kontext besitzen.
  • Gemäß bevorzugten Ausführungsformen kann der Wurzelidentifikator durch eine JVM 208 automatisch erzeugt werden. Jedes Mal, wenn ein Objekt in dem Haufen erzeugt wird, wird ein "neuer" Befehl an die JVM ausgegeben. Der neue Befehl erzeugt vorzugsweise das Objekt und speichert es in dem Haufen. Um jedem neuen Objekt, das erzeugt worden ist, während der EGC aktiv war, einen Wurzelidentifikator zuzuordnen, kann vorzugsweise eine Modifikation des neuen Befehls vorgenommen werden. Zu Beginn kann der Wurzelidentifikator auf den Wert null gesetzt werden.
  • Mit Bezug auf die 48 wird nun ein beispielhafter Haufen, der den EGC verwendet, besprochen. Um die Funktionalität des EGC zu zeigen, sind fünf Ausführungsstufen gezeigt. Diese fünf Stufen werden lediglich dazu verwendet, den Betrieb des EGC zu erläutern. Der wirkliche Betrieb des EGC kann irgendeine gewünschte Anzahl von Stufen verwenden. Die erste Stufe (4) zeigt den Zustand des Haufens und der zugeordneten Datenstrukturen während der Ausführung der egc.start()-Funktion. Die zweite Stufe (5) zeigt den Zustand des Haufens und der zugeordneten Datenstrukturen, während der EGC aktiv ist und ein neues Objekt in dem Haufen erzeugt wird. Die dritte Stufe (6) zeigt den Zustand des Haufens und der zugeordneten Datenstrukturen, während der EGC aktiv ist und der Kontext von Wurzelobjekten modifiziert worden ist. Die vierte Stufe (7) zeigt den Zustand des Haufens und der zugeordneten Datenstrukturen während der Ausführung der egc.stop()-Funktion. Schließlich zeigt die fünfte Stufe (8) den Zustand des Haufens und der zugeordneten Datenstrukturen nach der Ausführung der egc.stop()-Funktion.
  • Durch Bezugnahme auf 4 kann der Haufen 350 in der ersten Ausführungsstufe erläutert werden. Obwohl irgendeine Anzahl von Wurzelobjekten in der Wurzelanordnung enthalten sein kann, sind drei Wurzelobjekte 302, 304 und 306 gezeigt, um die Besprechung zu erleichtern. Diese Objekte werden von dem Programmentwickler in die Wurzelanordnung 300 platziert. Die modifizierten Bits 314, 316 und 318 werden zu Beginn während des egc.start()-Aufrufs auf falsch gesetzt. Wie oben erläutert worden ist, werden die einem Wurzelobjekt zugeordneten modifizierten Bits auf wahr gesetzt, wenn eine PutRef-Operation an einem Objekt ausgeführt wird, dessen Wurzelidentifikator nicht null ist.
  • Die Haufenmengen-Datenstruktur enthält Bezugnahmen auf Objekte, die durch eine vorhergehende Instanz des EGC in dem Haufen belassen wurden und sich innerhalb eines Wurzelkontexts befinden. Zu Erläuterungszwecken kann die Haufenmenge 320 Bezugnahmen auf zwei solche Objekte 326 und 328 enthalten. Das Objekt 326 befindet sich innerhalb des Wurzelkontexts der Wurzel 302 (es liegt eine Bezugnahme zwischen der Wurzel 302 und dem Objekt 326 vor), während sich das Objekt 328 innerhalb des Wurzelkontexts der Wurzel 304 befindet (es liegt eine Bezugnahme zwischen der Wurzel 304 und dem Objekt 328 vor). Dementsprechend sind die Wurzelidentifikatoren der Objekte 326 und 328 auf 302 bzw. 304 gesetzt. Die Wurzelidentifikatoren werden während des anfänglichen egc.start()-Aufrufs und während jedes egc.stop()-Aufrufs gesetzt. Die Erreichmengen 308, 310 und 312 sowie die temporäre Menge 322 sind in der ersten Ausführungsstufe leer. Da das Objekt 330 nicht erzeugt wurde, während der EGC aktiv war, ist es nicht in der Haufenmenge 320 enthalten und wird für die Entfernung durch den EGC nicht berücksichtigt.
  • 5 zeigt den Haufen 350 in der zweiten Ausführungsstufe (Objekterzeugung in dem Haufen). Obwohl in dieser Stufe irgendeine Anzahl von Objekten erzeugt werden kann, sind zwei solche Objekte 352 und 354 gezeigt, um die Besprechung zu erleichtern. Die Objekte 352 und 354 werden erzeugt, während der EGC aktiv ist. Dementsprechend werden Bezugnahmen auf die Objekte 352 und 354 in die temporäre Menge 322 platziert. Außerdem werden die Wurzelidentifikatoren dieser Objekte auf 'null' gesetzt. Alle anderen Datenstrukturen bleiben in der zweiten Ausführungsstufe unverändert.
  • Unter Bezugnahme auf 6 wird nun der beispielhafte Haufen 350 in der dritten Ausführungsstufe (Objektkontextmodifizierung) erläutert. Zu Erläuterungszwecken ändert sich die Bezugnahme des Wurzelobjekts 304 von dem Objekt 328 zu dem Objekt 352 (durch Anwendung eines putref-basierten Operationscodes). Wenn ein putref-Operationscode an einem Objekt ausgeführt wird, verwendet das Laufzeitprogramm den Wurzelidentifikator jenes Objekts, um das modifizierte Bit des entsprechenden Wurzelobjekts auf wahr zu setzen. In 6 wird das putref an einem Objekt 304 ausgeführt, wobei der zugeordnete Wurzelidentifikator 360 gleich dem Objekt 304 ist, da das Objekt 304 selbst eine Wurzel ist. Somit wird das modifizierte Bit des Wurzelobjekts 304 auf wahr gesetzt. Alle anderen Datenstrukturen bleiben in der zweiten Ausführungsstufe unverändert.
  • 7 zeigt den Haufen 350 in der vieren Ausführungsstufe (egc.stop). Während dieser Stufe werden mehrere Schritte ausgeführt. Im ersten Schritt wird auf jedes Wurzelobjekt, dessen modifiziertes Bit auf wahr gesetzt ist, und zwar nur auf diese Wurzeln, eine Verfolgungsroutine angewandt. Die Verfolgungsroutine kann alle Objekte in dem Haufen, auf die von diesem Wurzelobjekt Bezug genommen wird, identifizieren. Alle während der Verfolgungsroutine für ein bestimmtes Wurzelobjekt identifizierten Objekte können in die Erreichmenge, die dem entsprechenden Wurzelobjekt zugeordnet ist, platziert werden. Da das dem Wurzelobjekt 304 zugeordnete modifizierte Bit beispielsweise auf wahr gesetzt ist, wird eine Verfolgungsroutine auf das Wurzelobjekt 304 angewandt. Bei der Verfolgungsroutine wird das Objekt 352 identifiziert und in die Erreichmenge 310 platziert. Vorzugsweise ist ein Objekt zu einer Zeit in nur einer Menge (Erreichmenge, Haufenmenge, temporäre Menge) enthalten. Somit wird die Bezugnahme auf das Objekt 352 aus der temporären Menge entfernt. Im zweiten Schritt, nachdem das Verfolgen für alle als modifiziert markierten Wurzeln erledigt ist, können alle noch in der temporären Menge 322 vorhandenen Objekte aus dem Speicher entfernt werden. In dem beispielhaften Fall wird das Objekt 354 entfernt. Der dritte Schritt des Algorithmus durchsucht die Haufenmenge, um zu ermitteln, ob ein Objekt aus einem Wurzelkontext entfernt worden ist. Der dritte Schritt wird nur dann ausgeführt, wenn ein Wurzelobjekt vorhanden ist, dessen modifiziertes Bit auf wahr gesetzt ist. Beim Durchsuchen der Haufenmenge kann ein Objekt, dessen Wurzelidentifikator sich verändert hat, aus dem Speicher entfernt werden. Beispielsweise befindet sich das Objekt 328 während dieser Ausführungsstufe in der Haufenmenge. Da der Wurzelidentifikator des Objekts 328 auf ein Wurzelobjekt Bezug nimmt, dessen Kontext sich verändert hat, kann das Objekt 328 durch den EGC aus dem Haufen entfernt werden. Das andere Objekt in der Haufenmenge, das Objekt 326 (6), wird nicht entfernt, da sein Wurzelidentifikator auf das Wurzelobjekt 302, dessen Kontext nicht modifiziert worden ist, Bezug nimmt. Der vierte Schritt während dieser Ausführungsstufe besteht darin, die Haufenmenge des EGC aufzubauen. Um die Haufenmenge aufzubauen, wird jede Erreichmenge eines Wurzelobjekts, dessen modifiziertes Bit auf wahr gesetzt ist, in die Haufenmenge gelegt. Die Erreichmengen des Wurzelobjekts werden daher leer.
  • Schließlich kann 8 einen Haufen 350 in der fünften Ausführungsstufe veranschaulichen. Wurzelobjekte werden vorzugsweise aus der Wurzelanordnung 300 gelöscht. Alle Objekte in der Haufenmenge verbleiben in dem Haufen 350. Da das Objekt 330 nicht erzeugt wurde, während eine vorhergehende Instanz des EGC aktiv war, verbleibt auch das Objekt 330 in dem Haufen 350. Alls anderen Objekte werden aus dem Haufen 350 entfernt. Alle Datenstrukturen sind nun in ihrem Anfangszustand, was ermöglicht, den EGC wieder zu aktivieren, wenn das egc.start() ausgeführt wird.
  • Fachleuten auf dem Gebiet werden zahlreiche Abwandlungen und Abänderungen offenbar, sobald die obige Offenbarung vollständig erkannt worden ist. Die folgenden Ansprüche sind so zu interpretieren, dass sie alle solche Abwandlungen und Abänderungen umfassen.

Claims (11)

  1. Elektronisches System (200), das umfasst: einen Prozessor; und einen mit dem Prozessor gekoppelten Speicher, wobei der Speicher ein oder mehrere Objekte speichert, die Bezugnahmen von Wurzelobjekten haben können, wobei das System dadurch gekennzeichnet ist, dass es ferner umfasst: eine Anwendungsprogrammierungsschnittstelle, die einen Zustand eines eingebetteten Datenmüllsammelobjekts steuert; wobei die Anwendungsprogrammierungsschnittstelle von einem Programm aufgerufen wird und das eingebetettete Datenmüllsammelobjekt Steuerdaten verwendet, um zu veranlassen, dass Objekte aus dem Speicher entfernt werden, wobei die entfernten Objekte jene Objekte umfassen, die erzeugt wurden, während das eingebettete Datenmüllsammelobjekt in einem aktiven Zustand war, und die keine Bezugnahmen von Wurzelobjekten haben, wobei die Steuerdaten ein jedem Wurzelobjekt zugeordnetes modifiziertes Bit enthalten, wobei das modifizierte Bit angibt, ob ein Kontext des Wurzelobjekts modifiziert worden ist, während der eingebettete Datenmüllsammler in einem aktiven Zustand war, und eine variable Anordnung (322) enthalten, wobei die variable Anordnung die Objekte angibt, die erzeugt wurden, während ein eingebettetes Datenmüllsammelobjekt in einem aktiven Zustand war und auf das ein Wurzelobjekt nicht Bezug genommen hat, wobei das eingebettete Datenmüllsammelobjekt Wurzelobjekte verfolgt, die ihren Kontext geändert haben, und jene Wurzelobjekte nicht verfolgt, die ihren Kontext nicht geändert gehabt hatten.
  2. System nach Anspruch 1, wobei der Zustand eines eingebetteten Datenmüllsammlers einen initialisierten Zustand, einen aktiven Zustand oder einen inaktiven Zustand umfasst.
  3. System nach Anspruch 2, wobei das einem Wurzelobjekt zugeordnete modifizierte Bit auf wahr gesetzt wird, wenn der Kontext des Wurzelobjekts geändert worden ist.
  4. System nach Anspruch 2, wobei die Modifikation des Kontexts des Wurzelobjekts ein Hinzufügen, ein Ändern oder ein Entfernen einer Bezugnahme in dem Kontext des Wurzelobjekts umfasst.
  5. System nach Anspruch 2, wobei aus dem Speicher zu entfernende Objekte ferner Objekte umfassen, die zugewiesen werden, wenn das eingebettete Datenmüllsammelobjekt in einem aktiven Zustand ist, und in der variablen Anordnung (322) weiterhin verbleiben, nachdem alle modifizierten Wurzeln verfolgt worden sind.
  6. System nach Anspruch 2, wobei das eingebettete Datenmüllsammelobjekt im selben Thread wie das Programm, das die Anwendungsprogrammierungsschnittstelle aufruft, läuft.
  7. System nach Anspruch 2, wobei die Wurzelobjekte durch das Programm erzeugt werden, das die Anwendungsprogrammierungsschnittstelle aufruft, und zu dem eingebetteten Datenmüllsammelobjekt geleitet werden.
  8. System nach Anspruch 2, das ferner eine zusätzliche Datenmüllsammlung für Objekte umfasst, die nicht erzeugt werden, während der eingebettete Datenmüllsammler in einem aktiven Zustand ist.
  9. Datenmüllsammelverfahren, das umfasst: Starten eines eingebetteten Datenmüllsammlers; Auswählen eines aus dem Speicher zu entfernenden Objekts, wobei der Speicher Wurzelobjekte enthält, die Bezugnahmen auf zugeordnete Objekte haben können; und Entfernen des ausgewählten Objekts; dadurch gekennzeichnet, dass das Auswählen des zu entfernenden Objekts umfasst: Identifizieren von Wurzelobjekten, deren Kontext geändert worden ist, unter Verwendung von Steuerdaten, die ein jedem Wurzelobjekt zugeordnetes modifiziertes Bit enthalten, wobei das modifizierte Bit angibt, ob ein Kontext des Wurzelobjekts modifiziert worden ist, während der eingebettete Datenmüllsammler in einem aktiven Zustand war, und eine variable Anordnung (322) enthalten, die jene Objekte angibt, die erzeugt wurden, während ein eingebettetes Datenmüllsammelobjekt in einem aktiven Zustand war, und auf die ein Wurzelobjekt nicht Bezug genommen hat, und Verfolgen der identifizierten Wurzelobjekte zu Objekten, auf die Bezug genommen wird, um zu bestimmen, welche Objekte einem Wurzelobjekt zugeordnet sind, dessen Kontext sich geändert hat; wobei das Entfernen des ausgewählten Objekts das Entfernen eines Objekts umfasst, das erzeugt wurde, während der eingebettete Datenmüllsammler aktiv war, und nicht als ein Wurzelobjekt, dessen Kontext sich geändert hat, bestimmt worden ist.
  10. Verfahren nach Anspruch 9, bei dem beim Start des eingebetteten Datenmüllsammlers ein jedem Wurzelobjekt zugeordnetes modifiziertes Bit gelöscht wird, woraufhin ein modifiziertes Bit eines Wurzelobjekts gesetzt wird, wenn sich der dem Wurzelobjekt zugeordnete Kontext geändert hat.
  11. Verfahren nach Anspruch 9, wobei das Verfolgen der identifizierten Wurzelobjekte das Verfolgen von Wurzelobjekten, deren Kontexte sich nicht geändert haben, nicht umfasst.
DE60318993T 2003-06-19 2003-06-19 Eingebettete Speicherbereinigung Expired - Lifetime DE60318993T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP03291506A EP1489518B1 (de) 2003-06-19 2003-06-19 Eingebettete Speicherbereinigung

Publications (2)

Publication Number Publication Date
DE60318993D1 DE60318993D1 (de) 2008-03-20
DE60318993T2 true DE60318993T2 (de) 2009-01-29

Family

ID=33396045

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60318993T Expired - Lifetime DE60318993T2 (de) 2003-06-19 2003-06-19 Eingebettete Speicherbereinigung

Country Status (5)

Country Link
US (1) US7565385B2 (de)
EP (1) EP1489518B1 (de)
JP (1) JP2005011349A (de)
KR (1) KR20040111149A (de)
DE (1) DE60318993T2 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886294B2 (en) * 2004-12-28 2011-02-08 Sap Ag Virtual machine monitoring
US20070100919A1 (en) * 2005-11-01 2007-05-03 Electronics And Telecommunications Research Institute Garbage collection unit and method thereof
KR100753821B1 (ko) 2005-11-01 2007-08-31 한국전자통신연구원 가비지 컬렉션 장치 및 그 방법
KR100809293B1 (ko) 2006-03-10 2008-03-04 삼성전자주식회사 가상 머신에서 스택을 관리하는 장치 및 그 방법
KR100737345B1 (ko) * 2006-03-28 2007-07-09 한국전자통신연구원 점진적인 가비지 콜렉션 수행 시에 순환적 가비지의 회수방법 및 장치
US8001336B2 (en) * 2007-03-02 2011-08-16 International Business Machines Corporation Deterministic memory management in a computing environment
US8914424B2 (en) * 2008-08-13 2014-12-16 Oracle America, Inc. Efficient object pinning in a multi-threaded environment
US8200718B2 (en) * 2009-07-02 2012-06-12 Roberts Michael L Parallelized, incremental garbage collector
KR100978630B1 (ko) * 2009-09-17 2010-08-27 (주)제이모바일 사전 검증 절차를 거치지 않은 자바 응용프로그램을 실행하는 방법
US8346821B2 (en) * 2010-05-07 2013-01-01 International Business Machines Corporation Orphan object tracking for objects having acquire-release semantics
EP2671161B1 (de) * 2011-01-31 2019-03-13 The MathWorks, Inc. System und verfahren zur bestimmung der lebensdauer eines gegenstandes in einer objektorientierten umgebung
US8892610B1 (en) 2011-07-29 2014-11-18 Google Inc. System and method for garbage collection pause reduction

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5819299A (en) * 1996-06-06 1998-10-06 Electric Communities Process for distributed garbage collection
US6629113B1 (en) * 1999-06-30 2003-09-30 International Business Machines Corporation Method and system for dynamically adjustable and configurable garbage collector
GB9907283D0 (en) * 1999-03-31 1999-05-26 Koninkl Philips Electronics Nv Memory reclamation method
US6237060B1 (en) * 1999-04-23 2001-05-22 Sun Microsystems, Inc. Cache management techniques
US6865585B1 (en) * 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
GB0027045D0 (en) * 2000-11-06 2000-12-20 Ibm Computer system with heap reset
US6611898B1 (en) * 2000-12-22 2003-08-26 Convergys Customer Management Group, Inc. Object-oriented cache management system and method
US7111294B2 (en) * 2001-01-16 2006-09-19 Microsoft Corporation Thread-specific heaps
US6542911B2 (en) * 2001-03-01 2003-04-01 Sun Microsystems, Inc. Method and apparatus for freeing memory from an extensible markup language document object model tree active in an application cache
US6999980B2 (en) * 2002-08-23 2006-02-14 Sun Microsystems, Inc. Eliminating write barriers for young objects

Also Published As

Publication number Publication date
EP1489518A1 (de) 2004-12-22
JP2005011349A (ja) 2005-01-13
EP1489518B1 (de) 2008-02-06
US20040260732A1 (en) 2004-12-23
KR20040111149A (ko) 2004-12-31
US7565385B2 (en) 2009-07-21
DE60318993D1 (de) 2008-03-20

Similar Documents

Publication Publication Date Title
DE69938218T2 (de) Vorrichtung und Verfahren zum Laden eines Java Anwendungsprogramms
DE69617509T2 (de) Vorrichtung und Verfahren zur Feststellung von Objekttypen in einem verteilten Objektsystem
DE69400406T2 (de) System und methode zur lokalisierung von geteilten bibliotheken
DE69522842T2 (de) Gleichzeitige Verarbeitung in parallelen und fast parallelen objektorientierten Systemen
DE69814170T2 (de) Inkrementeller freispeichersammler
DE69800909T2 (de) Verfahren und Vorrichtung zur Optimierung der präzisen Speicherbereinigung, bei der Programmschleifen mit Zeiger-Feldern verwendet werden
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE69923657T2 (de) Markierung von gespeicherten datenobjekten für garbage-kollektoren
DE60032694T2 (de) Speicherrückforderungsverfahren
DE69427174T2 (de) Dynamische Hochleistungsprogrammverknüpfung durch Cachespeicherung
DE69503065T2 (de) Objektorientierte vorrichtung für konfigurationsverlaufsverwaltung
DE69533530T2 (de) Verfahren und System zur dynamischen Aggregation von Objekten
DE69836796T2 (de) Datenverarbeiter mit lokalisierter gedächtnisreklamierung
DE69228621T2 (de) Objektorientiertes verteiltes Rechnersystem
DE69030551T2 (de) Prozess und Gerät zur Handhabung zeitaufwendiger und wiederverwendbarer Abfragen in einem objekt-orientierten Datenbankverwaltungssystem
DE69525706T2 (de) Vorrichtung und Verfahren zum Generieren des Zielsprachcodes durch Verwendung eines objektorientierten Codegenerators
DE69803624T2 (de) Verfahren und Vorrichtung zur generationellen Freispeichersammlung in einem gemeinsam verwendeten Heapspeicher mittels mehrerer Prozessoreinheiten
DE69425548T2 (de) Verfahren und Vorrichtung zur dynamischen Objektverbindungserzeugung
DE69503052T2 (de) Verbessertes objektorientiertes betriebssystem zum filtrieren von datenobjekten in einem fenster
DE68916853T2 (de) Unabhängige Programmlader für virtuelle Maschinenarchitektur.
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE60318993T2 (de) Eingebettete Speicherbereinigung
DE69923658T2 (de) Dynamische speicherplatzzuordnung
DE60102694T2 (de) Modulares computersystem und -verfahren
DE69525710T2 (de) Verfahren und System zur Steuerung von Funktionen einer Zielanwendung mit Hilfe steuerbarer Objekte

Legal Events

Date Code Title Description
8364 No opposition during term of opposition