DE69828969T2 - Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit quellen- und zielinstanzen eines partiell relokierten objektes assoziiert ist - Google Patents

Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit quellen- und zielinstanzen eines partiell relokierten objektes assoziiert ist Download PDF

Info

Publication number
DE69828969T2
DE69828969T2 DE69828969T DE69828969T DE69828969T2 DE 69828969 T2 DE69828969 T2 DE 69828969T2 DE 69828969 T DE69828969 T DE 69828969T DE 69828969 T DE69828969 T DE 69828969T DE 69828969 T2 DE69828969 T2 DE 69828969T2
Authority
DE
Germany
Prior art keywords
memory
instance
write
fromspace
oriented
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
DE69828969T
Other languages
English (en)
Other versions
DE69828969D1 (de
Inventor
Marc Tremblay
Michael James O'CONNOR
L. Guy STEELE
Sanjay Vishin
Ole Agesen
Steven Heller
R. Derek WHITE
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.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems 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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=25381348&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE69828969(T2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE69828969D1 publication Critical patent/DE69828969D1/de
Publication of DE69828969T2 publication Critical patent/DE69828969T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
    • G06F12/0276—Generational garbage collection
    • Y—GENERAL 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
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99956—File allocation
    • Y10S707/99957—Garbage collection

Description

  • HINTERGRUND DER ERFINDUNG
  • Bereich der Erfindung
  • Die vorliegende Erfindung betrifft Garbage-Collection (Speicherbereinigung) und im Besonderen Verfahren und Vorrichtungen zum Fördern von Garbage-Collection mit begrenzter Pausezeit.
  • Beschreibung der verwandten Technik
  • Traditionell geben die meisten Programmiersprachen die Verantwortung für dynamische Speicherallokation und -deallokation dem Programmierer. Beispielsweise wird in der Programmiersprache C Speicher von der malloc-Prozedur (oder ihren Varianten) aus dem Heap alloziert. Eine Zeigervariable p vorausgesetzt, verursacht die Ausführung von der Aussage p = malloc (sizeof(SomeStruct)) entsprechenden Maschinenanweisungen, dass die Zeigervariable p auf einen neu allozierten Speicher für ein Speicherobject einer zum Darstellen einer SomeStruct-Datenstruktur notwendigen Größe zeigt. Nach Gebrauch kann das von der Zeigervariablen p gekennzeichnete Speicherobjekt dealloziert oder freigesetzt werden, indem free (p) angefordert wird. Die Sprachen Pascal und C++ stellen analoge Leistungsmerkmale zur expliziten Speicherallokation und -deallokation bereit.
  • Leider kann dynamisch allozierter Speicher unerreichbar werden, wenn im Satz der Wurzelreferenzstellen für eine bestimmte Berechnung keine Referenz oder kein Zeiger auf den Speicher übrigbleibt. Speicherobjekte, die nicht mehr erreichbar sind, aber nicht freigesetzt wurden, werden Garbage genannt. Desgleichen kann mit einem Speicherobjekt assoziierter Speicher dealloziert werden, während er noch referenziert ist. In diesem Fall wurde eine hängende (dangling) Referenz erstellt. Im Allgemeinen kann die richtige Verwaltung eines dynamischen Speichers schwer sein. In den meisten Programmiersprachen ist für Datenstrukturen, die die Prozedur überleben, die sie erstellte, eine Heap-Allokation erforderlich. Wenn diese Datenstrukturen an weitere Prozeduren oder Funktionen weitergeleitet werden, kann es für den Programmierer oder Compiler schwierig oder unmöglich sein, den Punkt zu bestimmen, an dem sie unbedenklich dealloziert werden können.
  • Wegen dieser Schwierigkeit kann die Garbage-Collection, d.h. die automatische Wiederverwertung von Heap-alloziertem Speicher nach seiner letzten Verwendung durch ein Programm, ein attraktives alternatives Modell für dynamisches Speichermanagement sein. Garbage-Collection ist besonders attraktiv für funktionelle Sprachen, wie z.B. JAVATM (JAVATM und auf JAVA basierende Marken sind Marken oder eingetragene Marken der Sun Microsystems, Inc., in den Vereinigten Staaten und anderen Ländern), Prolog, Lisp, Smalltalk, Scheme, Eiffel, Dylan, ML, Haskell, Miranda, Oberon usw., die die gemeinsame Datennutzung (Data-Sharing), verzögerte Ausführung und allgemein weniger berechenbare Ausführungsaufträge als die prozeduralen Sprachen aufweisen. Siehe allgemein Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, pp. 1–41, Wiley (1996) für eine Besprechung von Garbage-Collection und den klassischen Algorithmen dafür.
  • Drei klassische Garbage-Collection-Verfahren sind die Reference Counting-, Mark-Sweep- und kopierende (Copying) Speicherbereinigung. Die erste, Reference Counting (Referenzzähler), basiert darauf, dass die Zahl der Menge von Referenzen, z.B. Zeiger, auf jedes Speicherobjekt von aktiven Speicherobjekten oder Wurzelreferenzstellen gepflegt wird. Wenn ein neues Speicherobjekt alloziert wird und ihm ein Zeiger zugewiesen wird, wird die Referenzzahl des Speicherobjekts auf eins gesetzt. Dann wird jedesmal, wenn ein Zeiger als Referenz auf ein Speicherobjekt gesetzt wird, die Referenzzahl des Speicherobjekts inkrementiert. Wenn eine Referenz auf das Speicherobjekt gelöscht oder überschrieben wird, wird die Referenzzahl dekrementiert. Speicherobjekte mit einer Referenzzahl von null sind unerreichbar und können als nutzlose Objekte (Garbage) gesammelt werden. Eine referenzzählende Garbage-Collector-Implementierung hat gewöhnlich ein zusätzliches Feld reference count (Referenzzahl), in jedem Speicherobjekt und beinhaltet als Teil von Neues-Objekt-, Objekt-löschen- und Zeiger-aktualisieren-Funktionen Inkrementier- und Dekrementierunterstützung.
  • Im Gegensatz dazu beinhalten Tracing-Collector-Verfahren das Durchlaufen von Referenzketten durch Speicher, um lebende, d.h. referenzierbare Speicherobjekte, zu identifizieren. Ein derartiges Tracing-Collector-Verfahren ist das Mark-Sweep- Verfahren, bei dem Referenzketten durch Speicher durchlaufen werden, um lebende Speicherobjekte zu identifizieren und zu markieren. Unmarkierte Speicherobjekte sind nutzlose Objekte (Garbage) und werden gesammelt und während einer separaten Sweep-Phase zu dem freien Pool zurückgebracht. Eine Mark-Sweep-Garbage-Collector-Implementierung hat meist ein zusätzliches Feld, z.B. ein Markierungsbit, in jedem Speicherobjekt. Mark-Compact-Collectors setzen dem traditionellen Mark-Sweep-Ansatz die Kompaktierung hinzu. Die Kompaktierung reloziert lebende Objekte, um nützliche Verringerungen der Fragmentierung zu erzielen. Die Kompaktierung kann auch bei Referenzzählverfahren eingesetzt werden.
  • Ein weiteres Tracing-Verfahren, Copying-Collection (kopierendes Sammeln), unterteilt Speicher (oder einen Teil davon) in zwei Semispace-Bereiche, von denen einer aktuelle Daten enthält und der andere alte Daten enthält. Kopierende Garbage-Collection beginnt durch Umkehren der Aufgaben der beiden Bereiche. Der Copying-Collector traversiert dann die lebenden Objekte in dem alten Bereich, FromSpace, und kopiert erreichbare Objekte in den neuen Bereich, ToSpace. Wenn alle lebenden Objekte in FromSpace durchlaufen und kopiert worden sind, besteht in ToSpace eine Nachbildung der Datenstrukturen. Im Wesentlichen sucht ein Copying-Collector lebende Objekte unter den nutzlosen Objekten heraus. Eine nützliche Nebenwirkung der Copying-Collection ist, dass lebende Objekte in den ToSpace kompaktiert werden, wodurch die Fragmentierung verringert wird.
  • Generationelle (Generational) Ansätze bauen auf den Beobachtungen auf, dass (1) Speicherobjekte meist jung sterben und dass (2) Tracing-Verfahren beträchtliche Ressourcen für Durchlaufen, Kopieren oder Relozieren von vergleichsweise langlebigen Objekten aufwenden. Generationelle Garbage-Collection-Schemata unterteilen den Heap in zwei oder mehr Generationen, wobei Objekte nach Alter getrennt werden, und konzentrieren Sammlungsbemühungen (oder wenigstens energischere Sammlungsbemühungen) auf die jüngere(n) Generation(en). Da die jüngste Generation klein ist, können mit Garbage-Collection verwandte Pausezeiten im Durchschnitt kurz gehalten werden. Garbage-Collection innerhalb einer Generation kann entweder durch Copying- oder Mark-Sweep-Collection erfolgen. Die Beförderung von Speicherobjekten von einer jüngeren in eine ältere Generation beinhaltet meist Kopieren.
  • Wegen der Kosten des Kopierens großer Objekte weisen einige generationelle Ansätze Bereiche für große Objekte auf. Siehe z.B. Ungar und Jackson, Tenuring Policies for Generation-based Storage Reclamation, ACM SIGPLAN Notices, 23(11), pp. 1–17 (1988), Ungar und Jackson, An Adaptive Tenuring Policy for Generation Scavengers, ACM Transactions on Programming Languages and Systems, 14(1), pp. 1–17 (1992). Meist besteht die Technik darin, ein großes Objekt in einen im generationellen Teil des Heaps gespeicherten Kopfteil und einen im Bereich für große Objekte gespeicherten Hauptteil zu trennen. Die Kopfteile werden wie andere Objekte herausgesucht, es werden aber keine Ressorcen zum Kopieren der Hauptteile aufgebraucht. Ungar und Jackson fanden, dass Pausezeiten um das Vierfache verringert werden konnten, indem 330 KByte einem Bereich für große Objekte zugewiesen wurden.
  • Für interaktive oder Echtzeit-Anwendungen ist die Kürze von Garbage-Collection-Pausen ein wichtiger Vorteil. Traditionelle Implentierungen von Tracing-Garbage-Collectors unterbrechen periodisch die Ausführung von Anwendungsprogrammen, um Speicher in der Suche nach Speicherregionen zu durchlaufen, die nicht mehr in Gebrauch sind. Leider erfordern harte Echtzeitsysteme Worst-Case-Garantien, dass Ergebnisse rechtzeitig berechnet werden. Selbst in nur interaktiven Systemen sollte die Pausezeit begrenzt und kurz sein. So genannte inkrementelle Garbage-Collection-Verfahren versuchen, langwierige Pausen zu vermeiden, die durch Start-und-Stopp-Bereinigung verursacht werden, und verschachteln stattdessen die Sammlung mit Anwendungsprogrammzyklen. Zum Erreichen dieses Ziels muss ein inkrementeller Collector Heap-Zugriffe durch den Collector und das Anwendungsprogramm (oft allgemeiner als Mutator bezeichnet) kohärent verwalten. Verzahnte Collectors, z.B. in einem Multiprozessor, weisen ähnliche, aber striktere Anforderungen für feinkörnige Snchronisation auf.
  • Allgemein werfen verschachtelte oder verzahnte relozierende Collectors Mehrfachleser-, Mehrfachschreibersynchronisationsprobleme auf. Sowohl Lese- als auch Schreibsperrenverfahren werden verwendet, um einen Mutator durch Ändern der Konnektivität des Speicherobjekt-Referenzgraphs auf eine Weise, die das Durchlaufen dieser durch den Collector stört, am Unterbrechen der Garbage-Collection zu hindern. Siehe z.B. Steele, Multiprocessing Compactifying Garbage Collection, Communications of the ACM, 18(9), pp. 495–508 (1975) (Schreibsperre, Mark-Sweep-Compact-Collection); Dijkstra et al., On-the-fly Garbage Collection: An Exercise in Cooperation, Communications of the ACM, 21(11), pp. 965–975 (1978) (Schreibsperre); Kung & Song, An Efficient Parallel Garbage Collection System and its Correctness Proof, IEEE Symposium on Foundations of Computer Science, pp. 120–131 (1977) (Schreibsperre); Baker, List Processing in Real-time on a Serial Computer, Communications of the ACM, 21(4), pp. 280–93 (1978) (Lesesperre, Copying-Collector); Brooks, Trading Data Space for Reduced Time and Code Space in Real-time Garbage Collection on Stock Hardware, in Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, Austin, Texas, pp. 256–262 (1984) (Schreibsperre, Copying-Collector); und Dawson, Improved Effectiveness from a Real-time Lisp Garbage Collector, Conference Record of the 1992 ACM Symposium on Lisp and Functional Programming, San Francisco, Kalifornien, pp. 159–167 (1982) (Schreibsperre, Copying-Collector).
  • Der Symbolics 3600 stellte Hardware-Lesesperren- und -Schreibsperrenunterstützung für Copying-Collection im Stil von Baker und zum Abfangen intergenerationeller Zeiger bereit. Siehe Moon, Architecture of the Symbolics 3600, Proceedings of the 12th Annual International Symposium on Computer Architecture, pp. 76–83 (1985). Die MIT Lisp-Maschine und der TI Explorer stellten ebenfalls Hardware-Lesesperrenunterstützung für Copying-Collection im Stil von Baker bereit. Nilsen und Schmidt beschreiben im US-Patent Nr. 5,560,003 ein Garbage-Collected-Speichermodul, das Hardware-Lese- und -Schreibsperren implementiert.
  • Zusätzlich zu der grundlegenden Herausforderung des Verwaltens von Mutator-Zugriffen zum Verhindern von Änderungen der Konnektivität des Speicherobjekt-Referenzgraphs auf eine Weise, die das Durchlaufen des Collectors davon stören würde, sollte ein Collector für die Relokation mit begrenzter Pausezeit die zum Relozieren eines großen und/oder populären Speicherobjektes erforderliche beträchtliche Zeitdauer ansprechen. Ein Garbage-Collector kann sicherstellen, dass Speicherobjekte innerhalb eines begrenzten Intervalls vollständig reloziert werden können, indem große Objekte, die mit dem begrenzten Intervall unverträglich sind, in einen Bereich für große Objekte abgeschoben werden, die mit einem nichtrelozierenden Verfahren gesammelt werden können (siehe z.B. Ungar und Jackson, Tenuring Policies for Generation-based Storage Reclamation, ACM SIGPLAN Notices, 23(11), pp. 1–17 (1988)) oder nicht gesammelt werden können. Ansätze für faules oder inkrementelles Kopieren werden aber bevorzugt.
  • Bakers Lösung bestand darin, in den Kopf großer Objekte ein zusätzliches Verbindungswort aufzunehmen. In einer FromSpace-Instanz des Objekts speicherte das Verbindungswort eine Weiterleitungsadresse zu einer ToSpace-Instanz des Objekts. Nach dem Setzen der Weiterleitungs- und Rückwärtsverbindungen wurde das Objekt inkrementell kopiert. Felder großer Objekte wurden wie kleine Objekte kopiert und auf Zeiger zurück in FromSpace-Objekte, die noch nicht kopiert worden waren, abgetastet. Baker benutzte die von einer Garbage-Collection-Variable, scan, definierte abgetastete/nicht abgetastete Grenze, um Schreibzugriffe auf das teilweise kopierte große Objekt zu lenken. Die Kosten von Bakers Schema, abgesehen von einem zusätzlichen Kopfwort, waren eine Software-Schreibsperre für Schreibvorgänge in die ToSpace-Instanz des großen Objekts. Wenn die Adresse größer als scan war, wurde der Schreibvorgang unter Verwendung der Rückwärtsverbindung in der OldSpace-Instanz durchgeführt; ansonsten wurde der Schreibvorgang in der NewSpace-Instanz durchgeführt.
  • Nilsen und Schmidt stellten eine Hardware-Lösung auf der Basis von Bakers Copying-Collector vor. Im Besonderen sahen Nilsen und Schmidt ein Garbage-Collected-Speichermodul vor, bei dem eine Hardware-Lesesperre die Illusion aufrecht erhält, dass das Sammeln abgeschlossen ist. Ein Hardware-Arbiter in dem Garbage-Collected-Speichermodul stellte eine Hardware-Lesesperre vom Baker-Typ bereit und stellte außerdem Lese- und Schreibsperren für Zugriffe in einen noch nicht kopierten Teil einer Objektinstanz in ToSpace bereit. Das Garbage-Collected-Speichermodul pflegte die Speicheradressregister, um den Anfang und das Ende des unkopierten Teils anzuzeigen. Lese- und Schreibzugriffe auf den unkopierten Teil wurden zur FromSpace-Instanz geleitet.
  • US 5 293 614 beschreibt einen weiteren Garbage-Collector, der eine Schreibsperre implementiert, die Objektaktualisierungen zu einer ersten und zweiten Instanz davon sendet.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß der vorliegenden Erfindung ist eine Vorrichtung zur Verwendung in einem Garbage-Collection-System zum Verwalten der Konsistenz von Speicherobjektinstanzen während der Relokation eines bestimmten Speicherobjekts in einem Computersystem vorgesehen, das Relokation des genannten bestimmten Speicherobjekts mit begrenzter Pausezeit bereitstellt, wobei die Vorrichtung einen Speicher umfasst, bei dem darin gebildete Objekte von jeweiligen FromSpace-Instanzen zu jeweiligen ToSpace-Instanzen davon relozierbar sind, wobei die Vorrichtung ferner gekennzeichnet ist durch: einen Kennzeichnerspeicher für teilweise relozierte Objekte, der aktualisiert werden kann, um eines der genannten Objekte, falls vorhanden, für das die Relozierung unvollständig ist, zu kennzeichnen, und eine Schreibsperre für einen speicherorientierten Speicherzugriff, die ausgeführt ist, um auf die genannte FromSpace-Instanz des genannten bestimmten Objekts abzuzielen, und für einen speicherorientierten Speicherzugriff zum Abzielen auf die genannte ToSpace-Instanz des genannten bestimmten Objekts, wobei die genannte Schreibsperre die Konsistenz zwischen der genannten ToSpace-Instanz und wenigstens einem kopierten Teil der genannten FromSpace-Instanz aufrecht erhält, und wobei die genannte Schreibsperre die inkrementelle Aktualisierung von Zeigern auf das genannte bestimmte Objekt zulässt, wobei die genannte Schreibsperre auf eine Übereinstimmung zwischen einem Objektkennzeichner für den genannten speicherorientierten Speicherzugriff und dem Inhalt des genannten Kennzeichnerspeichers für teilweise relozierte Objekte reagiert, wobei die genannte Schreibsperre in Reaktion auf die Übereinstimmung Speicherdaten für den genannten speicherorientierten Speicherzugriff zu der genannten FromSpace- und der genannten ToSpace-Instanz sendet.
  • Dementsprechend wurde entdeckt, dass eine Schreibsperre für Speichervorgänge in ein teilweise reloziertes großes und/oder populäres Speicherobjekt Implementierungen mit begrenzter Pausezeit von relozierenden Garbage-Collectors, einschließlich z.B. Copying-Collectors und Kompaktierung bietende Collectors, erleichtert. Kennzeichnerspeicherung für teilweise relozierte Objekte und eine darauf reagierende Schreibsperre erlauben die Unterbrechung der Relokation großer und/oder populärer Speicherobjekte durch eine Garbage-Collector-Implementierung, um Garantien für begrenzte Pausezeiten gegenüber einem Mutator-Prozess zu erfüllen.
  • Ein Kennzeichnerspeicher für teilweise relozierte Objekte, der für Schreibsperrenlogik zugängliche „Kopieren von"-Kennzeichner- und „Kopieren zu"-Kennzeichnerspeicherung hat, erlaubt der Schreibsperrenlogik, die Konsistenz zwischen FromSpace- und ToSpace-Instanzen eines teilweise relozierten Speicherobjekts ohne Software-Trap-Handler-Overhead aufrecht zu erhalten. Fakultativer „Wie weit"-Anzeigespeicher erleichtert die Unterscheidung durch die Schreibsperrenlogik zwischen einem kopierten Teil und einem unkopierten Teil des teilweise relozierten Speicherobjekts. Eine fakultative „Modus"-Anzeige erleichtert die Unterscheidung durch die Schreibsperrenlogik zwischen einer Kopierphase und einer Zeigeraktualisierungsphase der Relokation durch die Garbage-Collector-Implementierung. In einigen Ausgestaltungen können Zeigeraktualisierungs- und Kopierphasen überlappen. „Kopieren zu"-Kennzeichnerspeicherung erleichtert das Senden eines speicherorientierten Speicherzugriffs auf die FromSpace-Instanz zu der FromSpace- und der ToSpace-Instanz. Desgleichen erleichtert während der Zeigeraktualisierung „Kopieren zu"- und „Kopieren von"-Kennzeichnerspeicherung das Senden eines speicherorientierten Speicherzugriffs auf die FromSpace-Instanz oder die ToSpace-Instanz zu der FromSpace- und auch der ToSpace-Instanz.
  • Einige Ausgestaltungen unterscheiden eventuell nicht zwischen Zeigeraktualisierungs- und Kopierphasen oder zwischen kopierten und unkopierten Teilen des teilweise relozierten Objekts. Darüber hinaus erlaubt „Kopieren zu"- und „Kopieren von"-Kennzeichnerspeicherung zwar vorteilhaft, dass die Schreibsperrenlogik die Konsistenz zwischen FromSpace- und ToSpace-Instanz eines teilweise relozierten Speicherobjekts ohne Software-Trap-Handler-Overhead aufrecht erhält, aber einige Ausgestaltungen können einen solchen Software-Trap-Handler aufweisen. Verschiedene alternative Funktionalitätszuweisungen zwischen Schreibsperrenlogik und einem Trap-Handler für teilweise relozierte Objekte sind vorgesehen und fallen in den Umfang der Ansprüche.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung kann durch Bezugnahme auf die Begleitzeichnungen besser verständlich werden und ihre zahlreichen Aufgaben, Merkmale und Vorteile können fachkundigen Personen ersichtlich gemacht werden.
  • 1a und 1b (die hierin kollektiv als 1 bezeichnet werden) sind jeweils ein Blockdiagramm einer beispielhaften Ausgestaltung eines Hardware-Prozessors einer virtuellen Maschine, der Unterstützung für Garbage-Collector-Implementierungen mit begrenzter Pausezeit gemäß dieser Erfindung aufweist.
  • 2 ist eine Abbildung der „zugrunde liegenden" Beziehungen zwischen Software- und Hardware-Komponenten einer JAVA-Anwendungsumgebung mit Hardware-Prozessor (1) und Software-Komponenten einer beispielhaften Implementierung einer JAVA virtuellen Maschine.
  • 3 illustriert mehrere mögliche Zusätze (Add-ons) für den Hardware-Prozessor von 1.
  • 4a und 4b (die hierin kollektiv als 4 bezeichnet werden) sind Abbildungen einer Ausgestaltung eines Kennzeichnerspeichers für teilweise relozierte Objekte und eines beispielhaften Speicherobjekt-Referenzgraphs gemäß einer Semispace-Speicherorganisation für einen Copying-Garbage-Collector vor dem Kopieren.
  • 5 ist eine Abbildung des Kennzeichnerspeichers für teilweise relozierte Objekte und die Semispace-Speicherorganisation von 4 während des Kopierens eines großen Objekts von FromSpace zu ToSpace.
  • 6 ist eine Abbildung von Zugriffen eines Copying-Collector-Prozesses und eines Mutator-Prozesses von FromSpace- und ToSpace-Teilen eines Sammel-Speicherbereichs, der ein teilweise reloziertes großes Objekt aufweist. 6 illustriert die Funktionsweise einer Schreibsperre des Hardware-Prozessors von 1 in Verbindung mit dem Kennzeichnerspeicher für teilweise relozierte Objekte der 4 und 5.
  • 7 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit einer Sperre zu einer Kopieren-von-Instanz eines teilweise relozierten Objekts und einem Trap-Handler dafür.
  • 8 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit einer Hardware-Sperre zu Speichervorgängen zu einer Kopieren-von-Instanz eines teilweise relozierten Objekts und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit Kopieren-von- und Kopieren-zu-Instanz-Kennzeichnern. Die Ausgestaltung von 8 sendet selektiv Speichervorgänge zu der Kopieren-von-Instanz und der Kopieren-zu-Instanz des teilweise relozierten Objekts.
  • 9 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit einer Hardware-Sperre zu Speichervorgängen zu einer Kopieren-von-Instanz eines teilweise relozierten Objekts und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit einem Kopieren-von-Instanz-Kennzeichner, einem Kopieren-zu-Instanz-Kennzeichner und einem Kennzeichner für die Kopiert/Unkopiert-Grenze. Die Ausgestaltung von 9 leitet oder sendet Speichervorgänge je nach dem Zustand der teilweisen Relokation des teilweise relozierten Objekts selektiv, um inkrementelles Kopieren zuzulassen.
  • 10 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit Sperren zu Kopieren-von- und Kopieren-zu-Instanzen eines teilweise relozierten Objekts und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit Kopieren-von- und Kopieren-zu-Instanz-Kennzeichnern. Die Ausgestaltung von 10 lässt inkrementelles Kopieren und die inkrementelle Zeigeraktualisierung zu.
  • 11 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit Sperren zu Speichervorgängen zu Kopieren-von- und Kopieren-zu-Instanzen eines teilweise relozierten Objekts und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit einem Kopieren-von-Instanz-Kennzeichner, einem Kopieren-zu-Instanz-Kennzeichner, einem Kennzeichner für die Kopiert/Unkopiert-Grenze und einem Garbage-Collection-Phasenkennzeichner. Die Ausgestaltung von 11 leitet oder sendet selektiv Speichervorgänge je nach dem Zustand der teilweisen Relokation des teilweise relozierten Objekts und der Garbage-Collection-Phase, um inkrementelles Kopieren und die inkrementelle Zeigeraktualisierung zuzulassen.
  • 12 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit Sperren zu Ladevorgängen von einer Kopieren-von-Instanz eines teilweise relozierten Objekts und zu Speichervorgängen zu der Kopieren-von-Instanz und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit einem Kopieren-von-Instanzkennzeichner, einem Garbage-Collection-Phasenanzeiger und einem Trap-Handler für teilweise relozierte Objekte. Die Ausgestaltung von 12 leitet oder sendet selektiv Speichervorgänge und leitet selektiv Ladevorgänge selektiv, um inkrementelles Kopieren und die inkrementelle Zeigeraktualisierung und in einigen Variationen überlappende Kopieren-von- und Kopieren-zu-Instanzen zuzulassen.
  • 13 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit Sperren zu Ladevorgängen von einer Kopieren-von-Instanz eines teilweise relozierten Objekts und zu Speichervorgängen zu der Kopieren-von-Instanz und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit einem Kopieren-von-Instanzkennzeichner, einem Kopieren-zu-Instanzkennzeichner und einem Garbage-Collection-Phasenanzeiger. Die Ausgestaltung von 13 leitet oder sendet selektiv Speichervorgänge und leitet selektiv Ladevorgänge um, um inkrementelles Kopieren und die inkrementelle Zeigeraktualisierung zuzulassen.
  • 14 ist eine Abbildung einer Ausgestaltung eines Garbage-Collection-Systems mit begrenzter Pausezeit mit Sperren zu Ladevorgängen von einer Kopieren-von-Instanz eines teilweise relozierten Objekts und zu Speichervorgängen zu der Kopieren-von-Instanz und mit einem Kennzeichnerspeicher für teilweise relozierte Objekte mit einem Kopieren-von-Instanzkennzeichner, einem Kopieren-zu-Instanzkennzeichner, einem Kennzeichner für die Kopiert-/Unkopiert-Grenze und einem Garbage-Collection-Phasenanzeiger. Die Ausgestaltung von 13 leitet oder sendet selektiv Speichervorgänge und leitet selektiv Ladevorgänge um, um inkrementelles Kopieren, die inkrementelle Zeigeraktualisierung und überlappende Kopieren-zu- und Kopieren-von-Instanzen zuzulassen.
  • 15 ist eine Abbildung des Betriebs eines Garbage-Collection-Systems mit begrenzter Pausezeit, der überlappende FromSpace- und ToSpace-Teile eines teilweise relozierten großen Objekts zulässt.
  • 16 ist eine Abbildung eines Objektreferenz(objectref)-Formats gemäß einer Ausgestaltung dieser Erfindung.
  • 17A ist eine Abbildung eines Objektformats gemäß einer Ausgestaltung dieser Erfindung.
  • 17B ist eine Abbildung eines alternativen mit Handle versehenen Objektformats gemäß einer Ausgestaltung dieser Erfindung.
  • Die Benutzung derselben Bezugssymbole in verschiedenen Zeichnungen zeigt ähnliche oder identische Teile an.
  • BESCHREIBUNG DER BEVORZUGTEN AUSGESTALTUNG(EN)
  • Im Folgenden wird eine ausführliche Beschreibung der besten erwogenen Ausführungsart für die Erfindung dargelegt. Die Beschreibung soll die Erfindung veranschaulichen und darf nicht als begrenzend ausgelegt werden.
  • Zu der architekturellen Unterstützung für Implementierungen mit begrenzter Pausezeit von relozierenden Garbage-Collectors zählen Speicher zum Kennzeichnen von Stellen, von denen (und, in einigen Ausgestaltungen, zu denen) ein großes und/oder populäres Speicherobjekt reloziert wird. Ein großes Objekt, wie hierin benutzt, ist ein beliebiges Speicherobjekt einer/eines solchen Größe, Struktur oder Inhalts, dass die Relokation des vollständigen Speicherobjekts, möglicherweise mit Aktualisierungen von Referenzen darauf, unter Worst-Case-Bedingungen mit Garantien für begrenzte Pausezeit einer Garbage-Collector-Implementierung unverträglich sein kann. Ausgestaltungen gemäß der vorliegenden Erfindung weisen unterschiedliche Grade an Konservatismus mit Bezug auf operative Definitionen eines großen Objekts auf. Beispielsweise können einige Ausgestaltungen eine Größenschwelle einsetzen, während andere in der Berechnungsart für große Objekte Referenzzahlen beinhalten können. Noch andere Ausgestaltungen, besonders diejenigen, die im Wesentlichen auf Hardware basieren, können die hierin beschriebene architekturelle Unterstützung ungeachtet der Speicherobjektgröße nutzen. Ein populäres Objekt, wie hierin benutzt, ist ein beliebiges Speicherobjekt, das eine Referenzzahl hat, so dass die Relokation des Speicherobjekts, einschließlich Aktualisierungen von Referenzen darauf, unter Worst-Case-Bedingungen mit Garantien für begrenzte Pausezeit einer Garbage-Collector-Implementierung unverträglich sein kann. Wie oben weisen Ausgestaltungen gemäß der vorliegenden Erfindung unterschiedliche Grade an Konservatismus mit Bezug auf operative Definitionen eines populären Objekts auf.
  • Allgemein können Ausgestaltungen gemäß der vorliegenden Erfindung hierin beschriebene architekturelle Unterstützung zum Relozieren von großen Objekten, populären Objekten, großen und populären Objekten, allen Objekten (einschließlich großen und/oder populären Objekten, aber nicht darauf begrenzt) usw. einsetzen. Derartige architekturelle Unterstützung kann zwar in Hardware, in Software oder in einer Kombination aus Hardware und Software bereitgestellt werden, aber Ausgestaltungen, in denen die architekturelle Unterstützung im Wesentlichen in Hardware erfolgt, bieten meist Vorteile hinsichtlich besserer Leistung und geringerem Speicherbedarf. Aus diesem Grund wird hierin eine beispielhafte Hardware-Prozessor-Ausgestaltung beschrieben. Auf der Grundlage dieser Beschreibung können fachkundige Personen aber alternative Ausgestaltungen erkennen, die in den Umfang der nachfolgenden Ansprüche fallen.
  • Der relozierende Garbage-Collector (Relocating Garbage Collector), wie hierin benutzt, ist ein beliebiger Garbage-Collector, der als Teil seines Betriebs Speicherobjekte reloziert, einschl. z.B. Copying-Collectors, generationelle Collectors und Collectors, die Kompatierung oder Objektrelokation zum Verringern der Fragmentierung und/oder Verbessern der Lokalität bereitstellen. Echtzeit-Implementierungen oder Implementierungen mit begrenzter Pausezeit derartiger relozierender Garbage-Collectors werden meist als ein inkrementeller Garbage-Collection-Softwareprozess implementiert, dessen Berechnungen mit Benutzerprozesstätigkeit verschachtelt sind. Fachkundige Personen werden aber verzahnte Garbage-Collection-Implementierungen auf der Basis der Beschreibung hierin erkennen. Des Weiteren werden fachkundige Personen geeignete Modifikationen, einschließlich dem Bereitstellen von Speicher zum Identifizieren von mehrfachen teilweise relozierten Objekten, zum Unterstützen von Implementierungen paralleler Collection erkennen.
  • Eine Ausgestaltung eines Prozessors für Anweisungen der JAVA virtuellen Maschine
  • 1 zeigt eine beispielhafte Hardware-Ausgestaltung eines Prozessors für Virtuelle-Maschine-Anweisungen 100, im Folgenden Hardware-Prozessor 100 genannt, der Unterstützung für relozierende Garbage-Collection mit begrenzter Pausezeit gemäß der vorliegenden Erfindung beinhaltet und Prozessorarchitektur-unabhängige JAVA Virtuelle-Maschine-Anweisungen direkt ausführt. Die Leistung des Hardware-Prozessors 100 beim Ausführen von Virtuelle-Maschine-Anweisungen ist meist besser als High-End-CPUs, wie der Intel PENTIUM-Mikroprozessor oder der Sun Microsystems ULTRASPARC-Prozessor (alle SPARC-Marken werden unter Lizenz benutzt und sind Marken oder eingetragene Marken von SPARC International, Inc., in den Vereinigten Staaten und anderen Ländern. SPARC-Marken tragende Produkte basieren auf einer von Sun Microsystems, Inc. entwickelten Architektur. PENTIUM ist eine Marke der Intel Corp. von Sunnyvale, Kalifornien), wobei die gleichen Virtuelle-Maschine-Anweisungen mit einem Software-JAVA-Interpreter oder mit einem JAVA Just-in-Time(JTT-)Compiler interpretiert werden. Außerdem ist der Hardware-Prozessor 100 kostengünstig und weist einen niedrigen Energieverbrauch auf. Infolgedessen eignet sich der Hardware-Prozessor 100 gut für portable Anwendungen.
  • Weil der Hardware-Prozessor 100 eine Prozessorimplementierung für JAVA Virtuelle-Maschine-Anweisungen im Wesentlichen in Hardware bereitstellt, können 25–50 Kilobyte (KByte) Speicher, z.B. Festwertspeicher oder Arbeitsspeicher, die sonst von einem Software-Interpreter benötigt werden, eliminiert oder alternativ alloziert werden. Hardware-Unterstützung für Garbage-Collection stellt weitere Vorteile für eine JAVA Virtuelle-Maschine-Implementierung mit begrenztem Speicher bereit, indem Inline-Code für Garbage-Collection (z.B. vom Compiler gelieferte Lese- und/oder Schreibsperrenunterstützung) reduziert wird, eine bessere Nutzung von begrenztem Speicher gefördert wird und Garbage-Collection-Overheads und -Pausezeiten verringert werden. In Umgebungen, wo die Kosten eines großen Speichers untragbar sind, einschließlich z.B. einem Internet-Chip für Netzgeräte, einem Mobiltelefonprozessor, anderen integrierten Telekommunikationsschaltungen oder anderen kostengünstigen Anwendungen mit geringem Energieverbrauch wie eingebetteten Prozessoren und tragbaren Geräten, ist der Hardware-Prozessor 100 vorteilhaft.
  • Selbst in Umgebungen, in denen großer Speicher tragbar ist, reduziert Hardware-Unterstützung für Garbage-Collection mit Sperrenimplementierungen verbundene Oberheads, fördert eine bessere Speichernutzung und reduziert Pausezeiten für relozierende Garbage-Collector-Implementierungen. Im Besonderen ergibt der Hardware-Prozessor 100 Vorteile für Garbage-Collection-Verfahren und -Implementierungen im Rahmen einer beispielhaften Implementierung einer JAVA virtuellen Maschine. Auf der Grundlage der Beschreibung hierin erkennen fachkundige Personen aber Variationen für andere Implementierungen der JAVA virtuellen Maschine, einschließlich z.B. interpretierte und JIT-Compiler-Implementierungen der JAVA virtuellen Maschine, sowie andere nicht-JAVA virtuelle-Maschine-Implementierungen.
  • Eine virtuelle Maschine, wie hierin benutzt, ist eine abstrakte Rechenmaschine, die wie eine reale Rechenmaschine einen Anweisungssatz hat und verschiedene Speicherbereiche benutzt. Eine virtuelle Maschinenspezifikation definiert einen Satz von Prozessorarchitektur-unabhängigen Virtuelle-Maschine-Anweisungen, die von einer Virtuelle-Maschine-Implementierung ausgeführt werden. Allgemein kann eine Virtuelle-Maschine-Implementierung in Hardware (z.B. wie im Fall des Hardware-Prozessors 100), in Software (z.B. wie im Fall von interpretierten und JIT-Compiler-Implementierungen) oder in Hardware und Software sein. Jede Virtuelle-Maschine-Anweisung definiert eine spezifische durchzuführende Operation. Es ist nicht notwendig, dass die virtuelle Maschine die Computersprache, die zum Erzeugen von Virtuelle-Maschine-Anweisungen verwendet wird, oder die zugrunde liegende Implementierung der virtuellen Maschine versteht. Nur ein bestimmtes Format für Virtuelle-Maschine-Anweisungen muss verstanden werden. In einer beispielhaften Ausgestaltung sind die Virtuelle-Maschine-Anweisungen JAVA Virtuelle-Maschine-Anweisungen. Jede JAVA Virtuelle-Maschine-Anweisung hat wenigstens ein Byte, das anweisungsidentifizierende Informationen, Operanden und beliebige andere benötigte Informationen codiert.
  • In dieser Ausgestaltung verarbeitet der Hardware-Prozessor 100 (1) die Anweisungen der JAVA virtuellen Maschine, die Bytecodes beinhalten. Der Hardware-Prozessor 100 führt die meisten der Bytecodes direkt aus. Die Ausführung einiger der Bytecodes wird aber über Mikrocode implementiert. Lindholm & Yellin, The JA JAVATM Virtual Machine Specification (Addison-Wesley, 1996), ISBN 0-201-63452-X, das durch Bezugnahme in seiner Ganzheit hierin eingebunden ist, enthält einen beispielhaften Satz von Anweisungen der JAVA virtuellen Maschine. Der von einem Hardware-Prozessor 100 unterstützte jeweilige Satz von Virtuelle-Maschine-Anweisungen ist kein essentieller Aspekt dieser Erfindung. Hinsichtlich der Virtuelle-Maschine-Anweisungen können fachkundige Personen die Erfindung aber für einen bestimmten Satz von Virtuelle-Maschine-Anweisungen oder für Änderungen an der Spezifikation der JAVA virtuellen Maschine modifizieren.
  • In einer Ausgestaltung hat der Hardware-Prozessor 100 einen E/A-Bus und eine Speicherschnittstelle 110, eine Befehls-Cache-Einheit 120 mit Befehlscache 125, eine Befehls-Decoder-Einheit 130 mit Unschnell-Schnell-Übersetzer-Cache 131, eine vereinigte Ausführungseinheit 140, eine Stack-Management-Einheit 150 mit Stack-Cache 155, eine Daten-Cache-Einheit 160 mit Daten-Cache 165, und Programmzähler- und Trap-Steuerlogik 170. Die Unterstützung für hierin beschriebene Garbage-Collection-Merkmale ruht hauptsächlich in der Integer-Einheit 142 und dem Register 144 der Ausführungseinheit 140 mit etwas zusätzlicher Unterstützung in der Programmzähler- und Trap-Steuerlogik 170 (einschließlich z.B. Unterstützung zum Zwingen des Programmzählers zu einer nächsten JAVA Virtuelle-Maschine-Anweisung nach einem abfangenden (Trapping-)Speichervorgang). Jede dieser Einheiten wird unten beschrieben. Außerdem wird eine beispielhafte Ausgestaltung des Hardware-Prozessors 100 in der als WO 97/27536 veröffentlichten internationalen PCT-Anmeldung mit dem Titel „INSTRUCTION FOLDING FOR A STACK-BASED MACHINE" ausführlicher beschrieben.
  • 2 ist eine Abbildung einer „zugrunde liegenden" Beziehung zwischen Software- und Hardware-Komponenten einer JAVA-Anwendungsumgebung, wie z.B. einer Anwendungsumgebung, die von einem Hardware-Prozessor 100 (1) definiert wird und teilweise ausführbar ist. JAVA Anwendung-/Applet-Software 210 nutzt Software-Komponenten, die eine Applet-/Anwendungsprogrammierschnittstelle 220 mit den Software-Komponten AWT-Klassen 214, Netz- und E/A-Klassen 242 und JAVA OS-Fenster 243, JAVA OS-Grafik 248, TCP 244, NFS 245, UDP 246, IP 247, Ethernet 222, Tastatur 249 und Maus 221 definieren, die in einer Ausgestaltung JAVA Bytecodes aufweisen. In der Ausgestaltung von 2 können die Software-Komponenten JAVA OS-Grafik 248 und Ethernet 222 auch erweiterte Bytecodes einschließen, die über die von der Basislinien-Spezifikation der JAVA virtuellen Maschine definierten hinausgehen. Zu den Komponenten einer eingebetteten Anwendungsprogrammierschnittstelle (EAPI) 230 zählen Grundklassen 231 und Hardware- und Software-Komponenten der Implementierung der JAVA virtuellen Maschine 250 gemäß der Spezifikation der JAVA virtuellen Maschine.
  • Die Implementierung der JAVA virtuellen Maschine 250 hat Hardware-Prozessor 100 und darin ausführbaren Trap-Code zum Evaluieren von JAVA Virtuelle-Maschine-Anweisungen. Außerdem hat die Implementierung der JAVA virtuellen Maschine 250 Hardware-Unterstützung für erweiterte Bytecodes (einschließlich z.B. Zeigerspeicher-Bytecodes und Speicherzugriffssperren, die unten im Kontext der Garbage-Collection beschrieben werden); Software für Klassenlader 252, Bytecode-Verifier 253, Thread-Manager 254 und Garbage-Collector 251 sowie Mikrokernel 255. Die Implementierung der JAVA virtuellen Maschine 250 hat einen mit der Spezifikation der JAVA virtuellen Maschine konformen Teil 250a sowie implementierungsabhängige Teile. Die Spezifikation der JAVA virtuellen Maschine schreibt zwar vor, dass Garbage-Collection bereitgestellt wird, das jeweilige eingesetzte Garbage-Collection-Verfahren ist aber implementierungsabhängig.
  • Hierin im Kontext einer beispielhaften Ausgestaltung als Hardware-Prozessor 100 der Implementierung der JAVA virtuellen Maschine 250 beschriebene Architekturmerkmale für die Garbage-Collection sind speziell für generationelle Garbage-Collection-Verfahren ausgeführt. Auf der Grundlage dieser Beschreibung erkennen fachkundige Personen aber die Anwendung von Unterstützung für begrenzte Pausezeit dieser Erfindung für relozierende Collectors im Allgemeinen, darunter z.B. nichtgenerationelle Collector-Implementierungen, inkrementelle Mark-Compact-Collectors, Copying Collectors usw.
  • 3 illustriert mehrere mögliche Zusätze (Add-ons) für den Hardware-Prozessor 100 zum Schaffen eines komplizierteren Systems. Jede beliebige der acht gezeigten Funktionen, d.h. NTSC-Codierer 501, MPEG 502, Ethernet-Controller 503, VIS 504, ISDN 505, E/A-Controller 506, ATM-Assemblieren/Neuassemblieren 507 und Funkverbindung 508 unterstützende Schaltungen können in den gleichen Chip wie der Hardware-Prozessor 100 dieser Erfindung integriert werden.
  • Außerdem erkennen fachkundige Personen eine große Palette von den Hardware-Prozessor 100 einbindenden Computersystemen, darunter Ausgestaltungen des Hardware-Prozessors 100 mit einer beliebigen der oben beschriebenen Zusatzschaltungen. Eine beispielhafte Computersystemausgestaltung hat physischen Speicher (z.B. RAM und/oder ROM), Zugriffseinrichtungen für maschinenlesbare Datenträger (z.B. Diskette, CD-ROM, Band und/oder auf Speichertechnologie gestützte Zugriffseinrichtungen für maschinenlesbare Datenträger), Eingabe-/Ausgabegerätschnittstellen (z.B. Schnittstellen für Tastatur und/oder Zeigegeräte, für Sichtgeräte usw.) und Kommunikationsvorrichtungen und/oder -schnittstellen. Zu den geeigneten Kommunikationsvorrichtungen und/oder -schnittstellen gehören diejenigen für netz- und telefoniegestützte Kommunikation, für den Anschluss an Kommunikationsnetze einschließlich Drahtleitungs- und/oder drahtlose Abschnitte eines öffentlichen Wählnetzes, Privatnetze usw. In einigen Ausgestaltungen dieser Erfindung werden Anweisungsströme (einschließlich z.B. JAVA Bytecodes) über derartige Kommunikationsvorrichtungen oder -schnittstellen zur Ausführung durch den Hardware-Prozessor 100 gesendet und/oder empfangen.
  • Architekturelle Unterstützung für Garbage-Collection
  • Hardware-Prozessor 100 stellt Hardware-Unterstützung für verschiedene Garbage-Collection-Verfahren bereit, einschließlich relozierenden Collector-Verfahren, die als darin ausführbare Garbage-Collection-Software implementiert sind. Im Besonderen hat der Hardware-Prozessor 100 einen Kennzeichnerspeicher für teilweise relozierte Objekte und Sperrenunterstützung. In einigen Ausgestaltungen beinhaltet eine solche Sperrenunterstützung Schreibsperrenunterstützung für vom Programmierer auswählbares Filtern von Speichervorgängen und/oder Unterstützung für Ausführungszeitauflösung von Speicherbytecodes zu zeigerspezifischen Bytecodes zum Fördern des Abfangens (Trapping) von Zeigerspeichervorgängen.
  • Kennzeichnerspeicher für teilweise relozierte Objekte
  • 4A ist eine Abbildung einer Ausgestaltung eines Kennzeichnerspeichers für teilweise relozierte Objekte 410 mit einem Von-Feld (From-Feld) 411, einem Zu-Feld (To-Feld) 412 und einem Wie-weit-Feld (Howfar-Feld) 413. 4B zeigt Speicherteile FromSpace 420 und ToSpace 430 gemäß einem Copying-Collector-Verfahren. In einer generationellen Collector-Implementierung können die Teile FromSpace 420 und ToSpace 430 Semispace-Bereiche einer einzelnen Generation bzw. Teile von jungen und alten Generationsbereichen sein. Alternativ können die Teile FromSpace 420 und ToSpace 430 Semispace-Bereiche in einem nichtgenerationellen Collection-Bereich sein. Des Weiteren können die Bereiche FromSpace 420 und ToSpace 430 überlappen, einzeln zusammenhängend oder nichtzusammenhängend sein, haben nicht unbedingt eine feste Größe oder haben feste Stellen im Speicher. Außerdem werden in einigen Ausgestaltungen mehrere FromSpace- und ToSpace-Teile mit geeigneten Modifikationen an dem Kennzeichnerspeicher für teilweise relozierte Objekte 410 und den Sperren, die hierin beschrieben werden, unterstützt. 4B bildet einen ersten Referenzierungszustand von lebenden Speicherobjekten A, B, C und dem großen Objekt 450 vor dem Kopieren in den ToSpace 430 ab. Der Wurzelzeigersatz 440 ist für jeden beliebigen Wurzelzeigersatz in die Referenzstruktur repräsentativ, einschließlich z.B. Zeiger, die aus Einträgen des Operanden-Stacks und/oder dem von Stack-Cache 155 repräsentierten lokalen Variablenspeicher stammen.
  • 5 ist eine Abbildung eines zweiten Referenzierungszustands des Kennzeichnerspeichers für teilweise relozierte Objekte 410, des FromSpace 420 und des ToSpace 430 bei Unterbrechung der Relokation des großen Objektes 450. Lebende Objekte A und B wurden zu entsprechenden Instanzen A' und B' in ToSpace 430 kopiert. Bei der Unterbrechung des Kopierens hat das große Objekt 450 einen kopierten Teil 551 und einen unvollständig kopierten Teil 552. Der Inhalt des kopierten Teils 551 des großen Objekts 450 wurde zu einem entsprechenden Teil 551a einer ToSpace 430-Instanz des großen Objekts 450 kopiert. ToSpace-430-Speicher für den restlichen unvollständig kopierten Teil des großen Objekts 450 wird als Teil 552a gezeigt. Das Von-Feld 411 kennzeichnet das große Objekt 450 in FromSpace 420, Zu-Feld 412 kennzeichnet die entsprechende teilweise relozierte Instanz 450a des großen Objekts 450 und Wie-weit-Feld 413 kennzeichnet eine Grenze zwischen dem kopierten Teil 551 und dem unvollständig kopierten Teil 552 des großen Objekts 450. Ein Überlappungskopierrichtungsfeld (nicht gezeigt) ist fakultativ. In einer Ausgestaltung hat ein solches Kopierrichtungsfeld ein Kopierrichtungsbit, dessen Zustand eine Vorwärts- oder Rückwärtsrichtung für das Kopieren von überlappten FromSpace- und ToSpace-Instanzen anzeigt. In anderen Ausgestaltungen wird die Kopierrichtung von den relativen Werten des Von-Feldes 411 und des Zu-Feldes 412 abgeleitet, wie fachkundige Personen erkennen können.
  • Das Wie-weit-Feld 413 zeigt den Fortschritt beim Kopieren eines großen Objekts an und/oder aktiviert Schreibsperrenhardware und einen Trap-Handler für teilweise relozierte Objekte zum entsprechenden Handhaben von Mutatorzugriffen auf ein teilweise kopiertes großes Objekt. In der Ausgestaltung von 5 zeigt das Wie-weit-Feld 413 die Adresse im Speicher der Grenze zwischen dem kopierten Teil 551 und dem unkopierten Teil 552 an. Trotzdem werden fachkundige Personen auf der Grundlage dieser Beschreibung eine Reihe verschiedener geeigneter alternativer Codierungen erkennen, darunter z.B. einen Index ab der vom Von-Feld 411 angezeigten Speicherstelle, eine Anzeige einer entsprechenden Grenze in der ToSpace-Instanz 550a des großen Objekts 450 usw. Das Wie-weit-Feld 413 codiert jede derartige geeignete Anzeige.
  • In 6, auf die jetzt Bezug genommen wird, wird der Kennzeichnerspeicher 410 für das teilweise relozierte Objekt im Kontext des Mutator-Prozesses 610 und des Garbage-Collector-Prozesses 620 gezeigt. In der Ausgestaltung von 6 werden der Mutator-Prozess 610 und der Garbage-Collector-Prozess 620 jeweils von JAVA Virtuelle-Maschine-Anweisungen definiert, die von dem Hardware-Prozessor 100 ausführbar sind. Garbage-Collector-Prozess 620 beinhaltet jeden beliebigen relozierenden Collector. Die folgende Beschreibung ist zwar für den oben mit Bezug auf 5 beschriebenen Semispace-Copying-Collector, fachkundige Personen erkennen aber die Anwendbarkeit auf andere relozierende Collectors. Im Lauf des Kopierens des großen Objekts 450 von FromSpace 420 zu ToSpace 430 liest der Garbage-Collector-Prozess 620 aus dem Sammelbereich 630 und schreibt in ihn.
  • In einer Ausgestaltung aktualisiert der Garbage-Collector-Prozess 620 Von-Feld 411 und Zu-Feld 412 am Anfang des Kopierens des großen Objekts 450 und aktualisiert das Wie-weit-Feld 413 während des Kopierens, so dass das Wie-weit-Feld 413 bei der Unterbrechung durch den Mutator-Prozess 610 die Grenze zwischen dem kopierten Teil 551 und dem unkopierten Teil 552 anzeigt. In Ausgestaltungen für einem simultanen Ablauf von Mutator-Prozess 610 und Garbage-Collection-Prozess 620 (z.B. in einem Multiprozessor) wird das Sperren (Lock) von Wie-weit-Feld 413 bereitgestellt und fachkundige Personen werden geeignete Verfahren dafür erkennen. Alternative Ausgestaltungen können fakultativ auf inkrementelles Aktualisieren des Wie-weit-Feldes 413 zugunsten einer Aktualisierung bei Unterbrechung verzichten.
  • Mutator-Prozess 610 liest aus dem und schreibt in den Speicher, der den Sammelbereich 630 hat. In einer Ausgestaltung hat der Hardware-Prozessor 100 Unterstützung durch Integer-Einheit 142 für eine Sperre 660, die Objektreferenzinformationen (z.B. eine objectref) mit Inhalt des Von-Felds 411, des Zu-Felds 412 oder beiden vergleicht. Eine Übereinstimmung mit Inhalt des Von-Felds 411 zeigt an, dass das referenzierte Objekt die FromSpace 420-Instanz des teilweise relozierten großen Objekts 450 ist. Eine Übereinstimmung mit Inhalt des Zu-Felds 412 zeigt an, dass das referenzierte Objekt die teilweise kopierte ToSpace 430-Instanz 450a ist. In einigen Ausgestaltungen wird die Evaluierung des jeweiligen Feld-Offsets in das referenzierte Objekt zum Verfeinern der Handhabung kopierter und unkopierter Teile des referenzierten Objekts durch die Sperre 660 mit dem Inhalt des Wie-weit-Felds 413 verglichen.
  • In verschiedenen Ausgestaltungen, die unten spezifischer beschrieben werden, hat die Sperre 660 eine Schreibsperrenunterstützung, die auf den Kennzeichnerspeicher für teilweise relozierte Objekte 410 reagiert. In einigen Ausgestaltungen hat die Sperre 660 auch eine Lesesperrenunterstützung, die auf den Kennzeichnerspeicher für teilweise relozierte Objekte 410 reagiert. In einigen Ausgestaltungen hat die Sperre 660 Hardware-Lese- und/oder -Schreibsperrenunterstützung zum Abfangen zu einem Software-Trap-Handler für teilweise relozierte Objekte, der den Abfangzugriff (z.B. durch Senden eines Schreibzugriffs, Umleiten eines Schreibzugriffs, Umleiten eines Lesezugriffs oder Zulassen eines normalen Abschließens eines Zugriffs) entsprechend handhabt. In anderen Ausgestaltungen stellt eine Hardware-Lese- und/oder -Schreibsperre selbst ein geeignetes Handhaben ohne Software-Trap-Handler-Overhead bereit.
  • In einigen Ausgestaltungen wird Relokation mit begrenzter Pausezeit von Elementen der Sperre 660 bereitgestellt, die inkrementelles Kopieren eines großen und/oder populären Objekts erlauben, während Zeigeraktualisierungen daran über ein Objekt-Referenz-Handle erfolgen. In solchen Ausgestaltungen werden Zeigeraktualisierungen zu geraden populären Objekten trivial durch die Aktualisierung eines einzelnen Zeigers bereitgestellt, d.h. des Objekt-Referenz-Handles. In anderen Ausgestaltungen weist von Elementen der Sperre 660 bereitgestellte Relokation mit begrenzter Pausezeit Unterstützung für inkrementelles Aktualisierungen von Zeigern auf ein populäres und möglicherweise großes Objekt auf. Relokation mit begrenzter Pausezeit, wie hierin benutzt, beinhaltet Kopieren und Zeigeraktualisierung. Fachkundige Personen werden die Anwendbarkeit von hierin beschriebenen Ausgestaltungen auf die Relokation mit begrenzter Pausezeit von großen Objekten, auf Relokation mit begrenzter Pausezeit von populären Objekten und auf Relokation mit begrenzter Pausezeit von großen, populären Objekten erkennen. Objektreferenzierung mit und ohne Handle wird unten noch ausführlicher beschrieben.
  • Je nach dem/den von einer bestimmten Ausgestaltung des Hardware-Prozessors 100 unterstützten Garbage-Collection-Verfahren kann Schreib- und/oder Lesesperrenunterstützung bereitgestellt sein, um zu verhindern, dass der Mutator-Prozess 610 den Garbage-Collector-Prozess 620 stört, indem die Konnektivität des Speicherobjekt-Referenzgraphs so geändert wird, dass das Durchlaufen der Collectors durch ihn gestört wird. Beispielsweise sind in einer Ausgestaltung des Hardware-Prozessors 100 vom Programmierer auswählbare Hardware-Schreibsperren für intergenerationelle Zeigerspeichervorgänge, für alle Zeigerspeichervorgänge und für alle Speichervorgänge (einschließlich Unterstützung für gefilterte Sperrenvarianten von jedem) bereitgestellt.
  • In einer Ausgestaltung der Sperre 660 ist die Unterstützung für derartige zusätzliche Sperren in die oben beschriebene Sperre zu Speichervorgängen in ein teilweise reloziertes großes Objekt integriert.
  • In Ausgestaltungen gemäß 1 hat ein Trap-Handler für teilweise relozierte Objekte JAVA Virtuelle-Maschine-Anweisungsbytecodes, die auf dem Hardware-Prozessor 100 ausführbar sind und von der Programmzähler- und Trap-Steuerlogik 170 eingeleitet werden. Garbage-Collection-Traps, einschließlich z.B. ein Trap für teilweise relozierte Objekte, werden ausgelöst, bevor der Abfangschreibvorgang selbst evaluiert wird. Daher emuliert der Trap-Handler für teilweise relozierte Objekte 650 den abfangenden Schreibvorgang zusammen mit den zusätzlichen mit der Garbage-Collection verwandten Funktionen, um zu verhindern, dass der Prozessor unendlich abfängt. In einer Ausgestaltung zwingt die Programmzähler- und Trap-Steuerlogik 170 dann nach dem abfangenden Schreibvorgang den Programmzähler zur nächsten JAVA Virtuelle-Maschine-Anweisung. Auf der Grundlage der folgenden ausführlicheren Beschreibung werden fachkundige Personen eine Reihe gültiger Verhalten für einen Trap-Handler für teilweise relozierte Objekte erkennen, je nach den erzwungenen Konsistenzrichtlinien.
  • Garbage-Collection wurde zwar oben allgemein mit Bezug auf die veranschaulichende Ausgestaltung in 6 des Kennzeichnerspeichers für teilweise relozierte Objekte 410 mit Von-Feld 411, Zu-Feld 412, Wie-weit-Feld 413 und im Kontext einer Sperre 660, die möglicherweise einen Trap-Handler für teilweise relozierte Objekte aufweist, beschrieben, verschiedene alternative Ausgestaltungen sind aber ebenfalls geeignet. In vielen dieser alternativen Ausgestaltungen kann ein Trap-Handler für teilweise relozierte Objekte eliminiert werden und Mutator-Prozess-Zugriffe können mit Hardware-Sperrenunterstützung richtig gehandhabt werden, wodurch mit einem Trap-Handler verbundener Overhead verringert wird. Auf der Grundlage der folgenden Beschreibung von beispielhaften Ausgestaltungen werden fachkundige Personen verschiedene zusätzliche Kombinationen und Variationen erkennen, die in den Umfang der Ansprüche fallen.
  • Mit Kopieren-von-Instanz-Kennzeichnerspeicher verbundene Schreibsperre
  • 7 ist eine Abbildung einer Ausgestaltung mit einem Kopieren-von-Registerfeld mit einer assoziierten Schreibsperre. Im Besonderen hat die Ausgestaltung von 7 das Von-Feld 411 des Kennzeichnerspeichers für teilweise relozierte Objekte 410 (siehe 4), die Hardware-Schreibsperre 740 und den Trap-Handler für teilweise relozierte Objekte 750. In der Ausgestaltung von 7 wird das Von-Feld 411 in Registern 144 des Hardware-Prozessors 100 repräsentiert. Mutator-Prozess 610, Garbage-Collector-Prozess 620 und Trap-Handler für teilweise relozierte Objekte 650 weist im Hardware-Prozessor 100 ausführbare Software auf. Diese Ausgestaltung erleichtert das inkrementelle Kopieren großer Objekte. Ohne zusätzliche Unterstützung ist diese Ausgestaltung aber zum inkrementellen Aktualisieren großer Mengen von Zeigern auf die ToSpace 430-Instanz eines populären relozierten Objekts nicht so gut geeignet. Für Garbage-Collection-Systeme, in denen Objekte beispielsweise über Handles referenziert werden, wie unten mit Bezug auf 17B beschrieben wird, verringert eine solche Ausgestaltung aber trotzdem Hardware-Anforderungen und ist für Relokation mit begrenzter Pausezeit realisierbar, da Aktualisieren eines einzelnen Handles zu der ToSpace 430-Instanz trivial sein kann.
  • Der Mutator-Prozess 610 führt Lese- und Schreibzugriffe auf den und aus dem Sammelbereich 630 durch. Lesezugriffe werden von der Garbage-Collection-Unterstützung nicht beeinflusst. Schreibzugriffe werden aber von der Hardware-Schreibsperre 740 selektiv abgefangen. Die Hardware-Schreibsperre 740 löst den Trap-Handler für teilweise relozierte Objekte 750 in Reaktion auf eine Entsprechung zwischen dem Inhalt des Von-Felds 411 und dem mit dem Schreibzugriff 701 assozierten Ziel objectref aus. In dieser Ausgestaltung bestimmt der Trap-Handler für teilweise relozierte Objekte 750 Speicherplatz für die Kopieren-zu-Zielortinformationen, wie die sonst im Zu-Feld 412 gespeicherten, oder pflegt fakultativ Speicher dafür. Außerdem kann Garbage-Collection-Software fakultativ Speicher für Wie-weit-Informationen wie die sonst im Wie-weit-Feld 413 gespeicherten pflegen. Wenn der Mutator-Prozess 610 zu der FromSpace 420-Instanz des großen Objekts speichert, werden Speicherdaten entweder zu der Kopieren-von-Instanz 450 und der Kopieren-zu-Instanz 450A gesendet oder in Ausgestaltungen, die Speicher für Wie-weit-Informationen bereitstellen, wird der Wie-weit-Speicher überprüft und der Speichervorgang zu beiden Instanzen gesendet, wenn das Gespeichert-zu-Feld des großen Objekts bereits kopiert wurde, und ansonsten zu der Kopieren-von-Instanz 450 geleitet. Fachkundige Personen werden verschiedene Verfahren erkennen, mit denen der Garbage-Collector-Prozessor 620 die dem Trap-Handler für teilweise relozierte Objekte 750 verfügbaren Speichervariablen des Zu-Felds und des Wie-weit-Felds 751 aktualisieren kann. Die Aktualisierung 701 erfolgt nach einem solchen geeigneten Verfahren.
  • Wie oben beschrieben, aktualisiert der Garbage-Collector-Prozess 620 das Von-Feld 411 des Kennzeichnerspeichers für teilweise relozierte Objekte 410 zum Kennzeichnen der Kopieren-von-Instanz 450 des großen Objekts. In dieser Ausgestaltung stehen dem Mutator-Prozess 610 keine Zeiger auf die Kopieren-zu-Instanz zur Verfügung, bis das Handle für das große Objekt nach Abschluss des Kopierens aktualisiert worden ist. Daher brauchen keine Sperren für Zugriffe auf die Kopieren-zu-Instanz 450A aufrecht erhalten zu werden. Diese Ausgestaltung ist nicht für überlappte Kopieren-von- und Kopieren-zu-Instanzen konfiguriert, Unterstützung für überlappte Instanzen ist aber für viele relozierende Collector-Verfahren, z.B. generationelle heraussuchende (Scavenging) oder kopierende Collector-Verfahren, nicht nötig.
  • In einer Ausgestaltung wird die Hardware-Schreibsperre 740 von der Logik der Integer-Einheit 142 (1) bereitgestellt, die für die Evaluierung eines speicherorientierten Bytecodes (z.B. putfield_quick, putfield, aastore usw.) zuständig ist. In einer solchen Ausgestaltung fangt die logikimplentierende Hardware-Schreibsperre 740 Schreibvorgänge zu der Kopieren-von-Instanz ab, die durch den Inhalt des Von-Felds 411 gekennzeichnet wird. Beispielsweise wird das erwünschte Verhalten der Hardware-Schreibsperre 640A mit den folgenden Logikgleichungen beschrieben:
    Figure 00250001
    wobei gc_notify ein beispielhafter Trap-Handler ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Fakultativ können Wie-weit-Informationen als Wie-weit-Feld 413 in Registern 144 (siehe 4, in 7 nicht abgebildet) bereitgestellt werden, um das Abfangen durch die Hardware-Schreibsperre 740 besser nur auf jene Situationen zuzuschneiden, in denen Rundsenden notwendig ist, wodurch mit Aufrufen des Trap-Handlers für teilweise relozierte Objekte 750 verbundene Overheads verringert werden.
  • 8 ist eine Abbildung einer Ausgestaltung mit einem Kopieren-zu-Registerfeld (z.B. Zu-Feld 412) zusätzlich zu einem Kopieren-von-Registerfeld (z.B. Von-Feld 411) mit zugehöriger Schreibsperre 840. Die Ausgestaltung von 8 stellt eine Schreibsperre für Speichervorgänge zu Feldern eines Objekts bereit, die von dem Inhalt des Von-Felds 411 gekennzeichnet werden, und vorteilhaft den Trap-Handler für teilweise relozierte Objekte 750 und die mit ihm verbundenen Overheads eliminiert. Diese Ausgestaltung erleichtert das inkrementelle Kopieren (mit begrenzter Pausezeit) großer Objekte, wie das von 7 eignet es sich aber nicht so gut für die Aktualisierung mit begrenzter Pausezeit von großen Mengen von Zeigern auf die ToSpace 430-Instanz eines kopierten Objekts. Wie oben können Objektreferenzen mit Handle diese Begrenzung mildern, was allgemeine Relokation mit begrenzter Pausezeit selbst von populären großen Objekten erlaubt, wenn auch auf Kosten einer zusätzlichen Indirektionsebene.
  • Durch Pflegen eines Kopieren-zu-Registerfelds in Hardware, z.B. als Zu-Feld 412 in Registern 144, können Schreibzugriffe auf die Kopieren-von-Instanz von der Hardware-Schreibsperre 840 ohne Intervention durch den Software-Trap-Handler zu der Kopieren-von- und der Kopieren-zu-Instanz gesendet werden. In einer Ausgestaltung wird die Hardware-Schreibsperre 840 von der Logik der Integer-Einheit 142 (1) bereitgestellt, die für die Evaluierung eines speicherorientierten Bytecodes zuständig ist. In einer solchen Ausgestaltung sendet die logikimplementierende Hardware-Schreibsperre 840 store_data zu der Kopieren-von- und der Kopieren-zu-Instanz, die von objectref bzw. dem Inhalt des Zu-Felds 412 gekennzeichnet werden. Eine beispielhafte Hardware-Schreibsperre 840 wird mit den folgenden Logikgleichungen beschrieben:
    Figure 00260001
    wobei offset der Offset des mit dem speicherorientierten Bytecode assoziierten Zielfelds in das große Objekt ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Weil das Zu-Feld 412 für die Hardware-Schreibsperre 840 verfügbar ist, kann das Rundsenden in Hardware durchgeführt werden und der Software-Trap-Overhead wird eliminiert.
  • 9 ist eine Abbildung einer Ausgestaltung mit Kopieren-zu- und Wie-weit-Registerfeld (z.B. Zu-Feld 412 und Wie-weit-Feld 413) zusätzlich zu einem Kopieren-von-Registerfeld (z.B. Von-Feld 411) mit assoziierter Hardware-Schreibsperre 940. Die Ausgestaltung von 9 stellt eine Schreibsperre für Speichervorgänge zu Feldern eines Objekts bereit, die durch den Inhalt des Von-Felds 411 gekennzeichnet werden, und erlaubt es der Hardware-Schreibsperre 940 vorteilhaft, auf das Senden von Speichervorgängen zu einem noch nicht kopierten Teil des großen Objekts zu verzichten, während es den Trap-Handler für teilweise relozierte Objekte 650 und die mit ihm verbundenen Overheads eliminiert. Wie die obigen Ausgestaltungen erleichtert auch diese Ausgestaltung inkrementelles Kopieren von großen Objekten, ist aber für die Aktualisierung mit begrenzter Pausezeit von großen Mengen von Zeigern auf die ToSpace 430-Instanz eines kopierten Objekts nicht so gut geeignet. Wie zuvor können mit Handle versehene Objektreferenzen diese Begrenzung mildern, was allgemeine Relokation mit begrenzter Pausezeit selbst von populären großen Objekten erlaubt, wenn auch auf Kosten einer zusätzlichen Indirektionsebene.
  • Durch Pflegen eines Kopieren-zu-Registerfelds in Hardware, z.B. als Zu-Feld 412 in Registern 144, können Schreibzugriffe auf die Kopieren-von-Instanz von der Hardware-Schreibsperre 940 zu der Kopieren-von- und der Kopieren-zu-Instanz gesendet werden. Indem ferner ein Wie-weit-Registerfeld in Hardware, z.B. als Wie-weit-Feld 413 in Registern 144, gepflegt wird, kann das Rundsenden auf jene Schreibzugriffe begrenzt werden, für die das betreffende Zielfeld des Schreibzugriffes bereits zu ToSpace 430 kopiert wurde. In jedem Fall erfolgt die Handhabung des Schreibzugriffs auf das teilweise relozierte Objekt ohne Software-Trap-Handler-Intervention. In einer Ausgestaltung wird die Hardware-Schreibsperre 940 von der Logik der Integer-Einheit 142 (1) bereitgestellt, die für die Evaluierung eines speicherorientierten Bytecodes zuständig ist. In einer solchen Ausgestaltung sendet die logikimplementierende Hardware-Schreibsperre 940 store_data zu der Kopieren-von- und der Kopieren-zu-Instanz, wenn das Zielobjektfeld in einem bereits kopierten Teil des großen Objekts ist, und leitet store_data zu der Kopieren-von-Instanz, wenn das Zielobjektfeld in einem noch nicht kopierten Teil des großen Objektes ist. Eine beispielhafte Hardware-Schreibsperre 940 wird von den folgenden Logikgleichungen beschrieben.
    Figure 00270001
    Figure 00280001
    wobei offset der Offset des mit dem speicherorientierten Bytecode assoziierten Zielfelds in das große Objekt ist. In einigen Ausgestaltungen kann das Leiten von store_data zu der Kopieren-von-Instanz bereitgestellt werden, indem einfach der Schreibzugriff ohne Intervention der Hardware-Schreibsperre 940 normal abgeschlossen werden darf. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Weil das Wie-weit-Feld 413 für die Hardware-Schreibsperre 940 verfügbar ist, kann die Hardware-Schreibsperre 940 selektiv auf das Schreiben von store_data zu der Kopieren-zu-Instanz verzichten. Diese leichte Optimierung kann die Leistung verbessern, indem nur ein einziger Schreibvorgang durchgeführt wird, anstatt dass zwei Schreibvorgänge gesendet werden.
  • Mit Kopieren-von- und Kopieren-zu-Instanz-Kennzeichnerspeicher assoziierte Schreibsperre
  • Im Folgenden werden zusätzliche Ausgestaltungen mit Bezug auf die 10 und 11 beschrieben. Wie einige der bereits beschriebenen Ausgestaltungen nutzen diese zusätzlichen Ausgestaltungen Hardware-Unterstützung (z.B. eine Hardware-Schreibsperre und Kennzeichnerspeicher für teilweise relozierte Objekte 410) zum entsprechenden Handhaben von Schreibvorgängen zur FromSpace 420-Instanz eines teilweise relozierten großen Objekts ohne Intervention durch einen Software-Trap-Handler. Außerdem stellen diese zusätzlichen Ausgestaltungen aber eine Sperre für Schreibvorgänge zu der ToSpace 430-Instanz eines teilweise relozierten großen Objekts bereit. So unterstützen diese zusätzlichen Ausgestaltungen inkrementelles Kopieren eines großen Objekts und inkrementelles Aktualisieren von Zeigern auf ein populäres Objekt für allgemeine Relokation mit begrenzter Pausezeit von großen und/oder populären Objekten ohne mit Handle versehene Objektreferenzen.
  • In den Ausgestaltungen der 10 und 11 aktualisiert der Garbage-Collector-Prozess 620 Zeiger (z.B. objectref) auf das große Objekt inkrementell. Schreibzugriffe des Mutator-Prozesses 610 auf die FromSpace 420-Instanz oder die ToSpace 430-Instanz werden von einer Hardware-Schreibsperre, z.B. Hardware-Schreibsperre 1040 oder Hardware-Schreibsperre 1140, gesendet (oder entsprechend geleitet), so dass die zwei Instanzen „synchron" gehalten werden, während die objectrefs aktualisiert werden. Weil die zwei Instanzen synchron gehalten werden, ist die Speicherreferenzierungsstruktur zu Referenzierungszuständen robust, in denen sich einige objectrefs auf eine FromSpace 420-Instanz beziehen und andere sich auf die entsprechende ToSpace 430-Instanz beziehen. Die Aktualisierung mit begrenzter Pausezeit von objectrefs mit Bezug auf das große Objekt wird durch inkrementelles Aktualisieren derartiger objectrefs erzielt, so dass sie sich auf die ToSpace 430-Instanz (statt auf die FromSpace 420-Instanz) beziehen. Es ist zu beachten, dass die FromSpace 420-Instanz und die ToSpace 430-Instanz in den Ausgestaltungen von 10 und 11 nicht überlappen dürfen.
  • Die Hardware-Schreibsperre 1040, Bezug nehmend auf 10, stellt eine Sperre für Schreibzugriffe auf entweder die Kopieren-von-Instanz 450 oder die Kopieren-zu-Instanz 450A bereit. Die Hardware-Schreibsperre 1040 unterstützt inkrementelles Kopieren mit begrenzter Pausezeit, wie es oben mit Bezug auf die Hardware-Schreibsperre 840 beschrieben wird. Die Hardware-Schreibsperre 1040 reagiert auch auf das Kopieren-zu-Registerfeld (z.B. Zu-Feld 412). Schreibzugriffe auf die Kopieren-von-Instanz 450 oder die Kopieren-zu-Instanz 450A werden sowohl zu der Kopieren-von-Instanz 450 als auch der Kopieren-zu-Instanz 450A gesendet, so dass die Datenzustände der zwei Instanzen synchronisiert werden. Auf diese Weise können objectrefs auf das teilweise relozierte große Objekt inkrementell aktualisiert werden, da ein Lesezugriff auf eine der Instanzen dem gleichen Feldzustand zugeordnet wird.
  • In einer Ausgestaltung wird die Hardware-Schreibsperre 1040 von der Logik der Integer-Einheit 142 (1), die für das Evaluieren eines speicherorientierten Bytecodes zuständig ist, bereitgestellt. In einer solchen Ausgestaltung sendet die logikimplementierende Hardware-Schreibsperre 1040 store_data zu der Kopieren-von- und der Kopieren-zu-Instanz, die durch den Inhalt des Von-Felds 411 bzw. des Zu- Felds 412 gekennzeichnet wird. Eine beispielhafte Hardware-Schreibsperre 1040 wird von den folgenden Logikgleichungen beschrieben.
    Figure 00300001
    wobei offset der Offset des mit dem speicherorientierten Bytecode assoziierten Zielfelds in das große Objekt ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Weil das Von-Feld 411 und das Zu-Feld 412 für die Hardware-Schreibsperre 1040 verfügbar ist, können die davon jeweils identifizierten Speichervorgänge zu der Kopieren-von-Instanz 450 bzw. der Kopieren-zu-Instanz 450A erkannt werden und das Senden zu beiden Instanzen kann in Hardware ohne Software-Trap-Overhead durchgeführt werden.
  • 11 ist eine Abbildung einer Ausgestaltung, die ein Wie-weit-Registerfeld (z.B. Wie-weit-Feld 413) und eine Modusanzeige (z.B. Modusfeld 1114 der Register 144) hinzufügt. Wie in der Ausgestaltung von 10 stellt die Hardware-Schreibsperre 1140 eine Sperre für Schreibzugriffe auf die Kopieren-von-Instanz 450 oder die Kopieren-zu-Instanz 450A bereit. Die Hardware-Schreibsperre 1140 unterstützt inkrementelles Kopieren mit begrenzter Pausenzeit, indem sie sicherstellt, dass kopierte Teile der Instanzen FromSpace 420 und ToSpace 430 synchron gehalten werden. Die Hardware-Schreibsperre 1140 erlaubt dem Hardware-Prozessor 100 vorteilhaft, auf das Senden von Speichervorgängen zu einem noch nicht kopierten Teil des großen Objekts während einer Kopierphase zu verzichten, die in der Ausgestaltung von 11 von einem Copy-Moduszustandfeld 1114 angezeigt wird. Während einer Zeigeraktualisierungsphase, die von einem PTR_UPDATE-Moduszustandsfeld 1114 angezeigt wird, werden aber Schreibzugriffe auf die Kopieren-von-Instanz 450 oder die Kopieren-zu-Instanz 450A zu der Kopieren-von-Instanz 450 und auch der Kopieren-zu- Instanz 450A gesendet. Der Garbage-Collector-Prozess 620 aktualisiert das Modusfeld 1114, so dass es einer aktuellen Phase einer Relokation eines großen Objekts entspricht.
  • In einer Ausgestaltung wird die Hardware-Schreibsperre 1140 von der Logik der Integer-Einheit 142 (1), die für das Evaluieren eines speicherorientierten Bytecodes zuständig ist, bereitgestellt. In einer solchen Ausgestaltung sendet die logikimplementierende Hardware-Schreibsperre 1140 store_data zu der Kopieren-von- und der Kopieren-zu-Instanz, wenn das Zielobjektfeld in einem bereits kopierten Teil des großen Objektes ist oder wenn das große Objekt vollständig kopiert worden ist und die Relokation eine Zeigeraktualisierungsphase begonnen hat. Während der Kopierphase leitet die logikimplementiertende Hardware-Schreibsperre 1140 store_data zu der Kopieren-von-Instanz, wenn das Zielobjektfeld sich in einem noch nicht kopierten Teil des großen Objekts befindet. Eine beispielhafte Hardware-Schreibsperre 1140 wird von den folgenden Logikgleichungen beschrieben.
    Figure 00310001
    wobei im Moduszustandsfeld 1114 MODE eine Relokationsphase (z.B. COPY oder PTR_UPDATE) anzeigt und offset der Offset des mit dem speicherorientierten Bytecode assoziierten Zielfelds in das große Objekt ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Weil das Wie-weit-Feld 413 und das Modus-Feld 1114 für die Hardware-Schreibsperre 1140 verfügbar ist, kann die Hardware-Schreibsperre 1140 selektiv auf das Schreiben von store_data zu der Kopieren-zu-Instanz während der Kopierphase einer Relokation eines großen Objekts verzichten, wobei sie während der Zeigeraktualisierungsphase Schreibvorgänge sendet. Diese leichte Optimierung kann die Leistung verbessern, indem während der Kopierphase nur ein einziger Schreibvorgang durchgeführt wird, anstatt dass zwei Schreibvorgänge gesendet werden. Außerdem kann der Relokationsmodus dadurch angezeigt werden, dass der Garbage-Collector-Prozess 620 den Abschluss der Kopierphase in einem Zustand des Wie-weit-Felds 413 codiert. Fachkundige Personen werden erkennen, dass in den obigen Logikgleichungen ein Wert des Wie-weit-Felds 413 von weniger als oder gleich null (0) verwendet werden kann, um den Abschluss der Kopierphase zu codieren, wodurch das Modusfeld 1114 vermieden wird.
  • Mit dem Kopieren-von-Instanz-Kennzeichnerspeicher assoziierte Lese- und Schreibsperren
  • Im Folgenden werden zusätzliche Ausgestaltungen mit Bezug auf die 12 bis 14 beschrieben. Wie einige der bereits beschriebenen Ausgestaltungen nutzen diese zusätzlichen Ausgestaltungen Hardware-Unterstützung (z.B. eine Hardware-Schreibsperre und einen Kennzeichnerspeicher für teilweise relozierte Objekte 410) zum geeigneten Handhaben von Schreibvorgängen zu der FromSpace 420-Instanz eines teilweise relozierten großen Objekts. Diese zusätzlichen Ausgestaltungen stellen aber auch eine Sperre für Lesevorgänge aus einer FromSpace 420-Instanz eines teilweise relozierten großen Objektes bereit. So unterstützen diese zusätzlichen Ausgestaltungen sowohl Kopieren mit begrenzter Pausezeit als auch Aktualisierung mit begrenzter Pausezeit von Zeigern auf das große Objekt ohne mit Handle versehenen Objektreferenzen.
  • In den Ausgestaltungen der 12 bis 14 kopiert der Garbage-Collector-Prozess 620 das große Objekt während einer Kopierphase (MODE = COPY) aus einer FromSpace 420-Instanz zu einer ToSpace 430-Instanz und aktualisiert Zeiger (d.h. objectrefs) während einer Zeigeraktualisierungsphase (MODE = PTR_UPDATE) inkrementell. Während der Kopierphase der Relokation eines großen Objektes werden Schreibzugriffe des Mutator-Prozesses 610 zu der FromSpace 420-Instanz gesendet oder von einem Trap-Handler für teilweise relozierte Objekte, z.B. Trap-Handler für teilweise relozierte Objekte 1250 (12), oder mit einer Hardware-Schreibsperre, z.B. Hardware-Schreibsperre 1340 (13) oder Hardware-Schreibsperre 1440 (14), entsprechend geleitet. Während der Zeigeraktualisierungsphase der Relokation großer Objekte werden die Mutator-Prozess 610 Schreib- und Lesezugriffe zu der FromSpace 420-Instanz zu der ToSpace 430-Instanz umgeleitet.
  • 12 ist eine Abbildung einer Ausgestaltung mit einem Kopieren-von-Registerfeld mit assoziierten Lese- und Schreibsperren. Im Besonderen weist die Ausgestaltung von 12 Von-Feld 411, Hardware-Lesesperre 1242, Hardware-Schreibsperre 1241 und Trap-Handler für teilweise relozierte Objekte 1250 auf. Die Hardware-Lesesperre 1242 und die Hardware-Schreibsperre 1241 werden veranschaulichend als Lese- und Schreibsperren-Hardware 1240 gezeigt. Je nach der Implementierung können die Hardware-Schreibsperre 1241 und die Hardware-Lesesperre 1242 Hardware aber gemeinsam nutzen oder auf separater Hardware basieren. In einer Ausgestaltung stellt eine Logik der Integer-Einheit 142 (1), die für die Evaluierung von speicherorientierten Bytecodes zuständig ist, die Hardware-Schreibsperre 1241 bereit, und die Logik der Integer-Einheit 142, die für die Evaluierung von ladevorgangorientierten Bytecodes (z.B. getfield_quick, getfield, aaload usw.) zuständig ist, stellt die Hardware-Lesesperre 1242 bereit.
  • Der Mutator-Prozess 610 führt Lese- und Schreibzugriffe von dem und auf den Sammelbereich 630 durch. Ein bestimmter Lese- oder Schreibzugriff wird von der Lese- und Schreibsperren-Hardware 1240 selektiv abgefangen, wenn der Lese- oder Schreibzugriff auf die FromSpace 420-Instanz eines teilweise relozierten Objekts abzielt. Die Lese- und Schreibsperren-Hardware 1240 löst den Trap-Handler für teilweise relozierte Objekte 1250 in Reaktion auf eine Übereinstimmung zwischen dem Inhalt des Von-Felds 411 und der Ziel-objectref, die mit dem Schreibzugriff 701 oder dem Lesezugriff 1202 assoziiert ist. In einer Ausgestaltung spricht die Lese- und Schreibsperren-Hardware 1240 auf ein Modusfeld 1114 der Register 144 an, das das Verhalten der Hardware-Lesesperre 1242 auf der Basis des Zustands des Modusfelds 1114 ändert. In einer solchen Ausgestaltung fängt die Hardware-Lesesperre 1242 nur während der Zeigeraktualisierungsphase der Relokation großer Objekte selektiv ab.
  • Eine beispielhafte Hardware-Schreibsperre 1241 wird mit den folgenden Logikgleichungen beschrieben.
    Figure 00330001
    Figure 00340001
    wobei gc_notify ein Trap-Handler ist, wie ein Trap-Handler für teilweise relozierte Objekte 1250. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die andere Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Eine beispielhafte Hardware-Lesesperre 1242 wird mit den folgenden Logikgleichungen beschrieben.
  • Figure 00340002
  • Alternative Ausgestaltungen können bei entsprechender Handhabung durch den Trap-Handler für teilweise relozierte Objekte 1250 während der Kopier- und der Zeigeraktualisierungsphase der Relokation eines großen Objekts selektiv abfangen, wenn auch auf Kosten eines größeren Trap-Handler-Overheads.
  • Während der Kopierphase ermittelt der Trap-Handler für teilweise relozierte Objekte 1250 die Kopieren-zu-Zielortinformationen, wie die sonst in dem Zu-Feld 412 gespeicherten, oder pflegt fakultativ Speicher dafür. Außerdem kann der Trap-Handler für teilweise relozierte Objekte 1250 fakultativ Speicher für Wie-weit-Informationen pflegen, wie die sonst in dem Wie-weit-Feld 413 gespeicherten. Wenn der Mutator-Prozess 610 in die FromSpace 420-Instanz des großen Objektes speichert, werden die Speicherdaten (store data) entweder zu der Kopieren-von-Instanz 450 und der Kopieren-zu-Instanz 450A gesendet, oder in Ausgestaltungen, die Speicher für Wie-weit-Informationen bereitstellen, wird der Wie-weit-Speicher überprüft und der Speichervorgang wird zu beiden Instanzen gesendet, wenn das Gespeichert-zu-Feld des großen Objekts bereits kopiert wurde, und ansonsten direkt zu der Kopieren-von-Instanz 450 geleitet.
  • Während der Zeigeraktualisierungsphase leitet der Trap-Handler für teilweise relozierte Objekte 1250 Lese- und Schreibzugriffe, die auf eine FromSpace 420-Instanz eines teilweise relozierten großen Objekts abzielen, zu der ToSpace 430-Instanz davon. Wie zuvor ermittelt der Trap-Handler für teilweise relozierte Objekte 1250 die Kopieren-zu-Zielortinformationen, wie die sonst in dem Zu-Feld 412 gespeicherten, oder pflegt fakultativ Speicher dafür. In jedem Fall leitet der Trap-Handler für teilweise relozierte Objekte 1250 Schreib- und auch Lesezugriffe zu der ToSpace 430-Instanz um. So wird ein Lesezugriff auf das teilweise relozierte Objekt der ToSpace 430-Instanz zugeordnet, die garantiert aktuell ist.
  • Beispielhafte Schreib-Trap- und Lese-Trap-Funktionen für den Trap-Handler für teilweise relozierte Objekte 1250 sind wie folgt:
    Figure 00350001
    wobei read_destination das Ziel für einen ladevorgangorientierten Bytecode ist.
  • Allgemein ist durch Abfangen auferlegter Overhead für den Lesesperrenfall wahrscheinlich größer als in dem Fall, in dem nur eine Schreibsperre vorgesehen ist, weil Lesezugriffe in einem bestimmten Anweisungsstrom meist häufiger sind als Schreibzugriffe und auf jeden Fall zusätzlich zu Schreibzugriffen sind. Zum Teil aus diesem Grund ist die Hardware-Lesesperre 1242 für Lesevorgänge der Zeigeraktualisierungsphase aus der FromSpace 420-Instanz des teilweise relozierten großen Objekts selektiv. Die Hardware-Lesesperre 1242 kann aber fakultativ Lesevorgänge aus der FromSpace 420-Instanz des teilweise relozierten großen Objekts ungeachtet der Relozierungsphase abfangen. In einer solchen Ausgestaltung kann der Trap-Handler für teilweise relozierte Objekte 1250 zum intelligenten Handhaben einer Kopieren-von-Instanz 450 und einer Kopieren-zu-Instanz 450A, die überlappen, konfiguriert sein. 15 illustriert eine Überlappung von Von-Instanz 1560 und Zu-Instanz 1570, bei der ein kopierter Teil 1561 zu Teil 1571 der Zu-Instanz 1570 kopiert worden ist. Von-Feld 411, Zu-Feld 412 und Wie-weit-Feld 413 codieren den teilweise relozierten Objektzustand wie oben beschrieben. In der Ausgestaltung von 15 kopiert der Garbage-Collector-Prozess 620 das große Objekt von hinten nach vorne (oder vorne nach hinten), je nach der relativen Überlappung der Von-Instanz 1560 und der Zu-Instanz 1570. Zum Erleichtern überlappter Von- und Zu-Instanzen sendet der Trap-Handler für teilweise relozierte Objekte 1550 keine Schreibvorgänge und leitet stattdessen einen auf einen nicht kopierten Teil 1562 abzielenden Schreibvorgang zu der Von-Instanz 1560 und leitet einen auf einen kopierten Teil 1561 abzielenden Schreibvorgang zu der Zu-Instanz 1570. Eine geeignete Modifikation der Schreibvorgangs-Trap-Funktion des Trap-Handlers des teilweise relozierten Objekts 1250 ist wie folgt:
    Figure 00360001
    Figure 00370001
    wobei COPY_DIRECTION aus den relativen Positionen der Von-Instanz 1560 und der Zu-Instanz 1570, wie von dem Vom-Feld 411 bzw. dem Zu-Feld 412 codiert, feststellbar ist. Modifikationen der Lese-Trap-Funktion des Trap-Handlers für teilweise relozierte Objekte 1250 zum entsprechenden Umleiten von ladevorgangorientierten Zugriffen sind analog.
  • 13 ist eine Abbildung einer Ausgestaltung mit einem Kopieren-zu-Registerfeld (z.B. Zu-Feld 412) zusätzlich zu einem Kopieren-von-Registerfeld (z.B. Von-Feld 411) mit assoziierter Lese- und Schreibsperren-Hardware 1340. Wie oben hat diese Ausgestaltung eine Modusanzeige (z.B. Modus-Feld 1114 der Register 144), das von dem Garbage-Collector-Prozess 620 gepflegt wird, damit Lese- und Schreibsperren-Hardware 1340 zwischen einer Kopierphase und einer Zeigeraktualisierungsphase der Relokation großer Objekte unterscheiden kann. Verglichen mit der Ausgestaltung von 12 stellt die von 13 sowohl Lesesperren- als auch Schreibsperrenunterstützung in Hardware bereit (z.B. als Hardware-Lesesperre 1342 für Speichervorgänge zu Feldern eines Objekts, die durch den Inhalt des Von-Felds 411 gekennzeichnet werden, und eine Hardware-Schreibsperre 1341 zu Speichervorängen zu Feldern eines Objekts, die durch den Inhalt des Von-Felds 411 gekennzeichnet werden), wodurch der Trap-Handler für teilweise relozierte Objekte 1250 und die mit ihm verbundenen Overheads vorteilhaft eliminiert werden.
  • Durch Pflegen eines Kopieren-zu-Registerfelds in Hardware, z.B. als Zu-Feld 412 in den Registern 144, können Schreibzugriffe auf die Kopieren-von-Instanz während einer Kopierphase (MODE = COPY) zu der Kopieren-von- und der Kopieren-zu-Instanz von der Hardware-Schreibsperre 1341 ohne Software-Trap-Handler-Intervention gesendet werden. Während einer Zeigeraktualisierungsphase (MODE = PTR_UPDATE) werden Schreibzugriffe auf die Kopieren-von-Instanz von der Hardware-Schreibsperre 1341 ebenfalls ohne Intervention des Software-Trap-Handlers zu der Kopieren-zu-Instanz umgeleitet. Lesezugriffe von der Kopieren-von-Instanz werden während der Zeigeraktualisierungsphase auch von der Hardware-Lesesperre 1342 ohne Intervention des Software-Trap-Handlers zu der Kopieren-zu-Instanz umgeleitet. Kopierphasen-Lesezugriffe auf die Kopieren-von-Instanz werden normal abgeschlossen.
  • In einer Ausgestaltung wird die Lese- und Schreibsperren-Hardware 1340 von der Logik der Integer-Einheit 142 (1), die für die Evaluierung von Bytecodes zuständig ist, bereitgestellt. Die Hardware-Schreibsperre 1341 wird von der Logik der Integer-Einheit 142, die für die Evaluierung von speicherorientierten Bytecodes zuständig ist, bereitgestellt und die Hardware-Lesesperre 1342 wird von der Logik der Inter-Einheit 142, die für die Evaluierung von ladevorgangorientierten Bytecodes zuständig ist, bereitgestellt.
  • Während der Kopierphase sendet die logikimplementierende Hardware-Schreibsperre 1342 store_data zu der Kopieren-von- und der Kopieren-zu-Instanz, die durch objectref bzw. den Inhalt des Zu-Felds 412 gekennzeichnet werden, während die logikimplementieren Hardware-Schreibsperre 1342 während der Zeigeraktualisierungsphase store_data nur zu der Kopieren-zu-Instanz umleitet. Eine beispielhafte Hardware-Schreibsperre 1342 wird von den folgenden Logikgleichungen beschrieben.
  • Figure 00380001
  • Desgleichen wird eine beispielhafte Lesesperre 1341 von den folgenden Logikgleichungen beschrieben.
    Figure 00380002
    Figure 00390001
    wobei in jedem Fall offset der Offset des mit dem speicherorientierten Bytecode assoziierten Zielfelds in das große Objekt ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die die Hardware-Lesesperre 1341 und die Hardware-Schreibsperre 1342 kombinieren, sowie Implementierungen, die die Hardware-Schreibsperre 1342 mit anderer Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren. Weil das Zu-Feld 412 für die Hardware-Schreibsperre 1342 und die Hardware-Lesesperre 1341 verfügbar ist, kann das Rundsenden und Umleiten in Hardware durchgeführt werden und der Software-Trap-Overhead wird eliminiert.
  • 14 ist eine Abbildung einer Ausgestaltung, die ein Wie-weit-Registerfeld (z.B. Wie-weit-Feld 413) hinzufügt. Wie in der Ausgestaltung von 13 stellt die Lese- und Schreibsperren-Hardware 1440 Sperren für Lese- und Schreibzugriffe von der und auf die Kopieren-zu-Instanz 450 bereit. Die Lese- und Schreibsperren-Hardware 1440 lenkt Lese- und Schreibzugriffe außerdem je nachdem, ob das von einem speicher- oder ladevorgangorientierten Bytecode referenzierte Feld bereits zu der ToSpace 430-Instanz kopiert wurde, zu einer entsprechenden FromSpace 420- oder ToSpace 430-Instanz. In Verbindung mit dem Wie-weit-Feld 413 operierend erlaubt die Hardware-Schreibsperre 1441 dem Hardware-Prozessor 100 vorteilhaft, auf das Senden von Speichervorgängen zu einem noch nicht kopierten Teil des großen Objekts während einer von einem COPY-Zustandsmodusfeld 1114 angezeigten Kopierphase zu verzichten. Während der Zeigeraktualisierungsphase ist die ToSpace 430-Instanz garantiert aktuell; durch Umleiten von Lesezugriffen zu ihr erlaubt die Hardware-Lesesperre 1442 daher dem Hardware-Prozessor 100 vorteilhaft, auf das Senden von Speichervorgängen während der Zeigeraktualisierungsphase zu verzichten. Weil gesendete Speichervorgängen eleminiert sind, eignet sich die Ausgestaltung von 14 besonders zum Unterstützen von überlappenden FromSpace 420- und ToSpace 430-Instanzen.
  • In einer Ausgestaltung wird die Lese- und Schreibsperren-Hardware 1440 von der Logik der Integer-Einheit 142 (1), die für die Evaluierung von Bytecodes zuständig ist, bereitgestellt. Die Hardware-Schreibsperre 1441 wird von der Logik der Integer-Einheit 142, die für die Evaluierung von speicherorientierten Bytecodes zuständig ist, bereitgestellt und die Hardware-Lesesperre 1442 wird von der Logik der Inter-Einheit 142, die für die Evaluierung von ladevorgangorientierten Bytecodes zuständig ist, bereitgestellt. Eine beispielhafte Hardware-Schreibsperre 1442 wird von den folgenden Logikgleichungen beschrieben.
  • Figure 00400001
  • Desgleichen wird eine beispielhafte Hardware-Lesesperre 1341 von den folgenden Logikgleichungen beschrieben.
    Figure 00400002
    Figure 00410001
    wobei read_destination der Zielort für einen ladevorgangorientierten Bytecode ist und wobei in jedem Fall offset der Offset des mit speicher- oder ladevorgangorientiertem Bytecode assoziierten Zielfeldes in das große Objekt ist. Fachkundige Personen werden verschiedene geeignete Logikimplementierungen erkennen, einschließlich Logikimplementierungen, die die Hardware-Lesesperre 1441 und die Hardware-Schreibsperre 1442 kombinieren, sowie Implementierungen, die die Hardware-Schreibsperre 1442 mit anderer Schreibsperrenfunktionalität, wie intergenerationelles Zeigerspeicherungsabfangen, wie oben beschrieben, kombinieren.
  • Mit dem Kopieren-zu-Instanz-Kennzeichnerspeicher assoziierte Lese- und Schreibsperren
  • Zu einer Reihe von Variationen der Ausgestaltungen der 12 bis 14 zählen Lese- und Schreibsperren, die mit einem Kopieren-zu-Instanz-Kennzeichnerspeicher anstatt einem Kopieren-von-Instanz-Kennzeichnerspeicher assoziiert sind. Wie zuvor fügen diese Variationen aufeinanderfolgende zusätzliche Hardware-Unterstützungsebenen hinzu, z.B. Unterstützung des Von-Felds 411 und Wie-weit-Felds 413, um Software-Trap-Handler-Overhead zu eliminieren und überlappende Kopieren-von- und Kopieren-zu-Instanzen 450 und 450A zu berücksichtigen. Die Variationen unterstützen sowohl das Kopieren mit begrenzter Pausezeit als auch die Aktualisierung mit begrenzter Pausezeit von Zeigern auf ein teilweise reloziertes großes Objekt. Diese Variationen werden jetzt durch Analogie zu den Ausgestaltungen der 12 bis 14 beschrieben, und fachkundige Personen werden auf der Basis dieser Beschreibung geeignete Modifikationen erkennen.
  • Der Garbage-Collector-Prozess 620 aktualisiert Zeiger auf das große Objekt, d.h. von der FromSpace 420-Instanz davon zu einer ToSpace 430-Instanz davon, bevor er die Objektdaten kopiert. Auf diese Weise wird die Ordnung von Zeigeraktualisierungs- und Kopierphasen umgekehrt. Vorwärts-Lese- und -Schreibzugriffe von Lese- und Schreibsperren werden zu der Kopieren-zu-Instanz 450A anstelle der Kopieren-von-Instanz 450 geleitet. In einer Ausgestaltung fangen Hardware-Lese- und -Schreibsperren Zugriffe auf die Kopieren-zu-Instanz 450A ab, was einen Software-Trap-Handler für teilweise relozierte Objekte aufruft, der das eigentliche Weiterleiten zu der Kopieren-von-Instanz durchführt. Der Trap-Handler für teilweise relozierte Objekte kann fakultativ Speicher für Wie-weit-Informationen pflegen, wie z.B. die sonst in dem Wie-weit-Feld 413 gespeicherten. Wenn der Mutator-Prozess 610 zu der ToSpace 420-Instanz des großen Objekts speichert, werden Speicherdaten zu der Kopieren-zu-Instanz 450A geleitet, wenn das Gespeichert-zu-Feld des großen Objekts bereits kopiert worden ist, und ansonsten zu der Kopieren-von-Instanz 450 geleitet. Desgleichen wird, wenn der Mutator-Prozess 610 von der ToSpace 420-Instanz des großen Objekts lädt, der Ladevorgang aus der Kopieren-zu-Instanz 450A durchgeführt, wenn das Gespeichert-zu-Feld des großen Objekts bereits kopiert worden ist, und sonst aus der Kopieren-von-Instanz 450 durchgeführt. Unterstützung für die überlappten FromSpace 430- und ToSpace 430-Instanzen wird wie oben mit Bezug auf die Ausgestaltungen der 12 und 14 beschrieben bereitgestellt. Alternativ kann die Lesesperre, wenn keine Unterstützung für überlappende Regionen benötigt wird, Ladevorgänge zu der Kopieren-von-Instanz lenken und die Schreibsperre kann Speichervorgänge zu der Kopieren-von- und der Kopieren-zu-Instanz senden.
  • Wie oben kann der Software-Trap-Overhead eliminiert werden, indem mehr Register und komplexeres Verhalten in die Hardware gelegt wird. Beispielsweise weist eine Ausgestaltung das Zu-Feld 412 und das Von-Feld 411 auf. Eine Hardware-Schreibsperre, die auf Übereinstimmung zwischen einem Speicherziel und dem Zu-Feld 412 reagiert, sendet Speicherungen zu der Kopieren-zu-Instanz 450A und der Kopieren-von-Instanz 450. Eine Hardware-Lesesperre, die auf Übereinstimmung zwischen einer Ladequelle und dem Zu-Feld 412 reagiert, leitet Ladevorgänge zu der Kopieren-von- Instanz 450 um. Eine weitere Ausgestaltung weist zusätzlich zu dem Von-Feld 411 und dem Zu-Feld 412 das Wie-weit-Feld 413 auf. Die Hardware-Schreibsperre und die Hardware-Lesesperre leiten Speicher- und Ladevorgänge zu kopierten Teilen der Kopieren-zu-Instanz 450A und zu unkopierten Teilen der Kopieren-von-Instanz 450. Fachkundige Personen werden auf der Grundlage der vorhergehenden Beschreibung geeignete Logik für jede der Ausgestaltungen erkennen.
  • Objektreferenzierungsformate
  • 16 ist eine Abbildung einer Ausgestaltung einer Objektreferenz (objectref), wie sie in dem Hardware-Prozessor 100 repräsentiert ist. Drei Bits der objectref können für Garbage-Collection-Hinweise verwendet werden.
  • Ein zusätzliches Handle-Bit H zeigt an, ob das Objekt von der objectref direkt oder indirekt – durch ein Handle – referenziert wird. Die Handles stellen ein Referenzierungsverfahren bereit, das die Relokation von Speicherobjekten ohne Großaktualisierungen von Zeigern (oder objectrefs) dafür erleichtert, wenn auch auf Kosten einer zusätzlichen Indirektionsebene. Diese Felder werden beide ausgeblendet, bevor sie an die Integer-Einheit 142 (1) des Hardware-Prozessors 100 angelegt werden.
  • In einer Ausgestaltung des Hardware-Prozessors 100 und des Sammelbereichs 630 (6–14) wird ein Objekt 1700 im Speicher mit einem Kopfteil 1710 und einem Instanzvariablenspeicherteil 1720 dargestellt. Eine solche Ausgestaltung ist in 17A abgebildet. Der Kopfteil 1710 hat ein 32-Bit-Wort, das selbst einen Methodenvektortabellen-Basisteil 1712 zum Repräsentieren der Klasse des Objekts und fünf Bits zusätzlichen Speicher 1714 hat, die für den Synchronisierungsstatus des Objekts und Informationen für den Garbage-Collector reserviert sind. Fakultativ kann ein zweites Kopfwort, z.B. Monitor-Zeiger 1716, die Adresse einer dem Objekt zugeordneten Überwachung enthalten, wodurch alle fünf Bits des zusätzlichen Speichers 1714 in dem ersten Kopfwort für Garbage-Collection-Informationen verfügbar gemacht werden. In der Ausgestaltung von 17A zeigt eine Objektreferenz (objectref) auf die Lokation des Methodenvektortabellen-Basisteils 1712, um den Methodenaufrufungs-Overhead zu minimieren.
  • Drei Bits des Kopfteils 1710 stehen einem Garbage-Collector wie den Collector-Prozess 620 zur Verfügung. In dem Kopfteil 1710 werden drei Bits niedrigerer Ordnung (header[2:0]) und zwei Bits hoher Ordnung (header[31:30]) ausgeblendet, wenn der Kopfteil als ein Zeiger behandelt wird. Drei dieser Bits (header[31:20,2]) stehen dem Garbage-Collector zum Speichern von Informationen über das Objekt 1700 zur Verfügung. Bit 1 und Bit 0 können zum Enthalten von LOCK- und WANT-Bits für Objektsynchronisierung verwendet werden. Alternativ kann ein zweites Kopfwort, z.B. Monitor-Zeiger 1716, zum Aufrechterhalten des Synchronisierungsstatus des Objekts 1700 bereitgestellt werden, was alle fünf Bits für die Garbage-Collection-Unterstützung übriglässt. Wie die Bits für die Garbage-Collection-Unterstützung verwendet werden, hängt von dem/den jeweiligen Typen von im Collector-Prozess 620 implementierten Garbage-Collection-Verfahren und Garbage-Collection-Trap-Handler, falls vorhanden, ab. Mögliche Verwendungen sind Markierungsbits, Zählerbits zum Altern von Objekten in einer Generation usw. Wie oben beschrieben, stehen in einer fakultativen zweiten Kopfwortausgestaltung des Kopfteils 1710 fünf Bits einem Garbage-Collector wie dem Collector-Prozess 620 zur Verfügung.
  • In der Ausgestaltung von 17A beginnt der Instanzvariablenspeicherteil 1720 ein Wort nach dem Methodenvektortabellen-Basisteil 1712 und enthält Instanzvariablen des Objekts 1700. Das niedrigstwertige Bit einer objectref gibt an, ob die Referenz mit Handle ist (==1) oder nicht (==0). Ein alternatives „mit Handle versehenes" Objektformat ist in 17B abgebildet. Eine mit Handle versehene Referenz wird eingerichtet, wenn das Objekt 1700b erstellt wird, und alle nachfolgenden Referenzen gehen über das Handle, d.h. Speicherzeiger 1750b, zum Zugreifen auf das Objekt. Diese Unterstützung wird für einige Arten von Garbage-Collectors bereitgestellt, die die Kosten der Zeigeraktualisierung während der Objektrelokation durch Kopieren von Handles anstelle des zu Grunde liegenden Objektspeichers, einschließlich dem für Instanzvariablen, reduzieren.
  • Objektreferenzen mit Handle erlauben Garbage-Collection-Systemen, wie den oben mit Bezug auf die 7–9 beschriebenen, eine Leistung mit begrenzter Pausezeit für Zeigeraktualisierungen zu einem kopierten Objekt aufzuweisen. In anderen Garbage-Collection-Systemen, für die Zeigeraktualisierung mit begrenzter Pausezeit großer Mengen von Referenzierungszeigern von der dadurch bereitgestellten Sperrenkonfiguration unterstützt wird, beispielsweise in den oben mit Bezug auf die 10–14 beschriebenen Ausgestaltungen, sind direkte Objektreferenzen vorzuziehen.
  • Die Erfindung wird zwar mit Bezug auf verschiedene Ausgestaltungen beschrieben, es versteht sich aber, dass diese Ausgestaltungen veranschaulichend sind und dass der Umfang der Erfindung nicht auf sie begrenzt ist. Anspruchsbegriffe, wie erste Anweisung, zweite Anweisung, dritte Anweisung usw. dienen nur zur Kennzeichnung und dürfen nicht als eine besondere Ordnung erfordernd ausgelegt werden. Viele Variationen, Modifikationen, Zusätze und Verbesserungen der beschriebenen Ausgestaltungen sind möglich. Beispielsweise wurde die vorliegende Erfindung hierin zwar mit Bezug auf beispielhafte Ausgestaltungen bezüglich der JAVA Programmiersprache und der JAVA virtuellen Maschine beschrieben, sie ist aber nicht auf diese begrenzt und umfasst stattdessen Systeme, Artikel, Verfahren und Vorrichtungen für eine breite Palette von Prozessorumgebungen (virtuelle und physische). Außerdem wurden bestimmte beispielhafte Ausgestaltungen zwar bezüglich Hardware beschrieben, geeignete Virtuelle-Maschine-Implementierungen (JAVA-verwandte oder sonstige), die einen Kennzeichnerspeicher für teilweise relozierte Objekte und (eine) darauf ansprechende Sperre(n) gemäß der obigen Beschreibung einbinden, haben Software-Implementierungen von Virtuelle-Maschine-Anweisungsprozessoren wie einen Bytecode-Interpreter oder einen Just-in-Time(JIT)-Compiler. Diese Zusätze und Verbesserungen fallen in den von den folgenden Ansprüchen definierten Umfang der Erfindung.

Claims (30)

  1. Vorrichtung zur Verwendung in einem Garbage-Collection-System zum Verwalten der Konsistenz von Speicherobjektinstanzen während der Relokation eines bestimmten Speicherobjekts in einem Computersystem, das Relokation des genannten bestimmten Speicherobjekts mit begrenzter Pausezeit bereitstellt, wobei die Vorrichtung einen Speicher (630) umfasst, bei dem darin gebildete Objekte von jeweiligen FromSpace(420)-Instanzen zu jeweiligen ToSpace(430)-Instanzen davon relozierbar sind, wobei die Vorrichtung ferner gekennzeichnet ist durch: einen Kennzeichnerspeicher für teilweise relozierte Objekte (144, 410), der aktualisiert werden kann, um eine FromSpace(420)-Instanz und eine ToSpace(430)-Instanz eines bestimmten der genannten Objekte, falls vorhanden, für das die Relozierung unvollständig ist, zu kennzeichnen, und eine Schreibsperre (1040, 1140) für einen speicherorientierten Speicherzugriff, der auf die genannte FromSpace(420)-Instanz des genannten bestimmten Objekts abzielt, und für einen speicherorientierten Speicherzugriff, der auf die genannte ToSpace(430)-Instanz des genannten bestimmten Objekts abzielt, wobei die genannte Schreibsperre die Konsistenz zwischen der genannten ToSpace(430)-Instanz und wenigstens einem kopierten Teil der genannten FromSpace(420)-Instanz aufrecht erhält, und wobei die genannte Schreibsperre (1040, 1140) die inkrementelle Aktualisierung von Zeigern auf das genannte bestimmte Objekt zulässt, wobei die genannte Schreibsperre (1040, 1140) auf eine Übereinstimmung zwischen einem Objektkennzeichner für den genannten speicherorientierten Speicherzugriff und dem Inhalt des genannten Kennzeichnerspeichers für teilweise relozierte Objekte reagiert und wobei die genannte Schreibsperre (1040, 1140) in Reaktion auf die Übereinstimmung Speicherdaten für den genannten speicherorientierten Speicherzugriff zu der genannten FromSpace(420)- und der genannten ToSpace(430)-Instanz sendet.
  2. Vorrichtung nach Anspruch 1, bei der die genannte Schreibsperre selektiv auf das Senden von Speicherdaten verzichtet, wenn der genannte speicherorientierte Speicherzugriff auf einen unkopierten Teil der genannten FromSpace-Instanz abzielt und die genannten Speicherdaten stattdessen zu der genannten FromSpace-Instanz und nicht der genannten ToSpace-Instanz leitet.
  3. Vorrichtung nach Anspruch 1, bei der der genannte Kennzeichnerspeicher für teilweise relozierte Objekte ein FROM-Feld zum Kennzeichnen der genannten FromSpace-Instanz und ein TO-Feld zum Kennzeichnen der ToSpace-Instanz umfasst, wobei die genannte Schreibsperre in einen Speicherpfad eines Hardwareprozessors zu dem genannten Speicher gekoppelte Schreibsperrenlogik umfasst, wobei die genannte Schreibsperrenlogik auf eine Übereinstimmung zwischen einem Objektkennzeichner für den genannten speicherorientierten Speicherzugriff und dem Inhalt von dem genannten FROM-Feld oder dem genannten TO-Feld reagiert.
  4. Vorrichtung nach Anspruch 3, bei der die genannte Schreibsperrenlogik ein Speicherdatum für den genannten speicherorientierten Speicherzugriff der genannten FromSpace- und der genannten ToSpace-Instanz des genannten bestimmten Objekts zuführt, wodurch die genannte Konsistenz aufrecht erhalten wird.
  5. Vorrichtung nach Anspruch 3, bei der die genannte Schreibsperrenlogik ein Speicherdatum für den genannten speicherorientierten Speicherzugriff der genannten FromSpace-Instanz und, wenn ein Teil des genannten bestimmten Objekts, auf den der genannte speicherorientierte Speicherzugriff abzielt, zu der genannten ToSpace-Instanz kopiert wurde, auch der genannten ToSpace-Instanz zuführt, wodurch die genannte Konsistenz aufrecht erhalten wird.
  6. Vorrichtung nach Anspruch 1, ferner umfassend einen Teilkopiepositionsanzeiger zum Unterscheiden zwischen dem genannten kopierten Teil und einem unkopierten Teil der genannten FromSpace-Instanz, wobei die genannte Schreibsperre einen zweiten speicherorientierten Speicherzugriff, der auf den genannten kopierten Teil abzielt, zur genannten FromSpace- und zur genannten ToSpace-Instanz sendet, und wobei die genannte Schreibsperre einen dritten speicherorientierten Speicherzugriff, der auf den genannten unkopierten Teil abzielt, zur genannten FromSpace-Instanz und nicht zur genannten ToSpace-Instanz leitet.
  7. Vorrichtung nach Anspruch 1, ferner umfassend einen Teilkopiepositionsanzeiger zum Unterscheiden zwischen dem genannten kopierten Teil und einem unkopierten Teil der genannten FromSpace-Instanz oder der genannten ToSpace-Instanz, wobei die genannte Schreibsperre einen vierten speicherorientierten Speicherzugriff, der auf den genannten kopierten Teil der genannten FromSpace- oder der genannten ToSpace-Instanz abzielt, zur genannten FromSpace- und zur genannten ToSpace-Instanz sendet, und wobei die genannte Schreibsperre einen fünften speicherorientierten Speicherzugriff, der auf den genannten unkopierten Teil abzielt, zur genannten FromSpace-Instanz und nicht zur genannten ToSpace-Instanz leitet.
  8. Vorrichtung nach Anspruch 1, bei der die genannte Schreibsperre während einer Kopierphase der Relokation des genannten bestimmten Objekts einen sechsten speicherorientierten Speicherzugriff, der auf den genannten kopierten Teil abzielt, zur genannten FromSpace- und zur genannten ToSpace-Instanz sendet, wobei die genannte Schreibsperre während der genannten Kopierphase einen siebten speicherorientierten Speicherzugriff, der auf einen unkopierten Teil der genannten FromSpace-Instanz abzielt, zur genannten FromSpace-Instanz und nicht zur genannten ToSpace-Instanz leitet, und wobei die genannte Schreibsperre während einer Zeigeraktualisierungsphase einen achten speicherorientierten Speicherzugriff, der entweder auf die genannte FromSpace- oder die genannte ToSpace-Instanz abzielt, zur genannten FromSpace-Instanz und zur genannten ToSpace-Instanz sendet.
  9. Vorrichtung nach Anspruch 8, ferner umfassend: einen Teilkopiepositionsanzeiger zum Unterscheiden zwischen dem genannten kopierten Teil und dem genannten unkopierten Teil und einen Relokationsmodusanzeiger zum Anzeigen einer aktuellen Relokationsphase, die die genannte Kopierphase und die genannte Zeigeraktualisierungsphase beinhaltet, für das genannte bestimmte Objekt, wobei die genannte Schreibsperre auf den genannten Relokationsmodusanzeiger reagiert.
  10. Vorrichtung nach Anspruch 8, ferner umfassend: einen Teilkopiepositionsanzeiger zum Unterscheiden zwischen dem genannten kopierten Teil und dem genannten unkopierten Teil, wobei die genannte Zeigeraktualisierungsphase einem Teilkopiepositionsanzeigerzustand, der auf einen völlig kopierten Zustand für das genannte bestimmte Objekt hindeutet, entspricht.
  11. Vorrichtung nach Anspruch 1, ferner umfassend: einen Prozessor, der den genannten Kennzeichnerspeicher für teilweise relozierte Objekte und die genannte Schreibsperre ausgestaltet, und in von dem genannten Prozessor lesbarem Datenträger codierte und dadurch ausführbare Mutatorprozessanweisungen, wobei die genannten Mutatorprozessanweisungen eine Anweisung aufweisen, die dem genannten speicherorientierten Speicherzugriff entspricht, und in von dem genannten Prozessor lesbarem Datenträger codierte und dadurch ausführbare Garbage-Collector-Ablaufanweisungen, wobei die genannten Garbage-Collector-Ablaufanweisungen eine Anweisungsfolge zum inkrementellen Kopieren des genannten bestimmten Objekts von der genannten FromSpace-Instanz zu der genannten ToSpace-Instanz, zum inkrementellen Aktualisieren von Zeigern, die auf die genannte FromSpace-Instanz verweisen, zum Verweisen auf die genannte ToSpace-Instanz, und zum Erhalten des Kennzeichnerspeichers für teilweise relozierte Objekte in Übereinstimmung damit beinhalten, wobei die genannte Anweisungsfolge von den genannten Mutatorprozessanweisungen unterbrochen werden kann.
  12. Vorrichtung nach Anspruch 1, ferner umfassend: einen Prozessor, der den genannten Kennzeichnerspeicher für teilweise relozierte Objekte und die genannte Schreibsperre ausgestaltet, und in von dem genannten Prozessor lesbarem Datenträger codierte und dadurch ausführbare Mutatorprozessanweisungen, wobei die genannten Mutatorprozessanweisungen eine Anweisung aufweisen, die dem genannten speicherorientierten Speicherzugriff entspricht, und in von dem genannten Prozessor lesbarem Datenträger codierte und dadurch ausführbare Relokatorprozessanweisungen, wobei die genannten Relokatorprozessanweisungen eine Anweisungsfolge zum inkrementellen Kopieren des genannten bestimmten Objekts von der genannten FromSpace-Instanz zu der genannten ToSpace-Instanz, zum inkrementellen Aktualisieren von Zeigern, die auf die genannte FromSpace-Instanz verweisen, zum Verweisen auf die genannte ToSpace-Instanz und zum Erhalten des Kennzeichnerspeichers für teilweise relozierte Objekte in Übereinstimmung damit beinhalten, wobei die genannte Anweisungsfolge von den genannten Mutatorprozessanweisungen unterbrochen werden kann.
  13. Vorrichtung nach Anspruch 12, bei der die genannten Relokatorprozessanweisungen zum Durchführen eines der Folgenden ausgewählt sind: generationelle Garbage-Collection, Mark-Sweep-Compact-Garbage-Collection, kopierende Garbage-Collection und Heap-Kompaktierung mit begrenzter Pausezeit.
  14. Vorrichtung nach Anspruch 12, bei der die genannten Zeiger, die auf das genannte bestimmte Objekt verweisen, direkt auf das genannte bestimmte Objekt verweisen und bei der die genannten Relokatorprozessanweisungen ausgewählt sind, um eines der folgenden durchzuführen: generationelle Garbage-Collection, Mark-Sweep-Compact-Garbage-Collection, kopierende Garbage-Collection und Heap-Kompaktierung mit begrenzter Pausezeit.
  15. Vorrichtung nach Anspruch 12, bei der der genannte Prozessor einen Virtuelle-Maschine-Anweisungsprozessor umfasst.
  16. Vorrichtung nach Anspruch 12, bei der der genannte Prozessor einen Hardwareprozessor mit Registerspeicher und den genannten Kennzeichnerspeicher für teilweise relozierte Objekte und die genannte Schreibsperre ausgestaltende Logik umfasst.
  17. Vorrichtung nach Anspruch 1, bei der das genannte bestimmte Objekt ein sehr großes Objekt, ein populäres Objekt oder ein großes und populäres Objekt umfasst.
  18. Vorrichtung nach Anspruch 1, bei der die genannte Schreibsperre eine erste Schreibsperre zu speicherorientierten Speicherzugriffen, die auf die genannte FromSpace-Instanz abzielen, und eine zweite Schreibsperre zu speicherorientierten Speicherzugriffen, die auf die genannte ToSpace-Instanz abzielen, umfasst.
  19. Vorrichtung nach Anspruch 1, ein den genannten Kennzeichnerspeicher für teilweise relozierte Objekte und die genannte Schreibsperre ausgestaltender Hardwareprozessor, eine mit dem genannten Hardwareprozessor verbundene Kommunikationsvorrichtung zum Empfangen von Mutatorprozessanweisungen zur Ausführung auf dem genannten Hardwareprozessor verbunden ist, wobei die genannten Mutatorprozessanweisungen eine erste Anweisung beinhalten, die dem genannten speicherorientierten Speicherzugriff entspricht, und einen von dem genannten Hardware-Prozessor lesbaren Datenträger zum Codieren von auf dem genannten Hardwareprozessor ausführbaren Garbage-Collector-Prozessanweisungen zum inkrementellen Kopieren des genannten bestimmten Objekts und zum inkrementellen Aktualisieren von Zeigern auf dieses.
  20. Vorrichtung nach Anspruch 1, ferner umfassend einen ersten und einen zweiten Prozessor, die mit dem genannten Kennzeichnerspeicher für teilweise relozierte Objekte und dem genannten Speicherverbunden sind, wobei der genannte erste Prozessor die genannte Schreibsperre aufweist, wobei die genannte Relokation das inkrementelle Kopieren des genannten bestimmten Objekts durch einen Garbage-Collector-Prozessor umfasst und wobei die genannten speicherorientierten und die genannten ladevorgangorientierten Speicherzugriffe Schreib- bzw. Lesezugriffe durch einen auf dem genannten ersten Prozessor ausführbaren Mutatorprozess umfassen und wobei der genannte Kennzeichner für ein teilweise reloziertes Objekt von dem genannten Garbage-Collector-Prozess in Übereinstimmung mit dem genannten inkrementellen Kopieren des genannten bestimmten Objekts gehalten wird.
  21. Vorrichtung nach Anspruch 20, bei der der genannte zweite Prozessor einen Spezial-Garbage-Collection-Prozessor umfasst.
  22. Vorrichtung nach Anspruch 20, bei der der genannte zweite Prozessor in den genannten Speicher integriert ist, wobei der genannte zweite Prozessor und der genannte Speicher zusammen ein Garbage-Collected-Speichermodul umfassen.
  23. Vorrichtung nach Anspruch 1, bei dem der genannte Kennzeichnerspeicher für teilweise relozierte Objekte ferner aktualisiert werden kann, um ein zweites der genannten Objekte zu kennzeichnen, für das die Relokation unvollständig ist, und wobei die genannte Vorrichtung ferner Folgendes umfasst: einen ersten und einen zweiten Garbage-Collection-Prozessor, die mit dem genannten Kennzeichnerspeicher für teilweise relozierte Objekte und mit dem Speicher verbunden sind, wobei das Relozieren des genannten bestimmten und des genannten zweiten Objekts inkrementelles Kopieren davon durch den genannten ersten bzw. den genannten zweiten Garbage-Collection-Prozessor umfasst.
  24. Verfahren zum Relozieren eines Speicherobjekts mit begrenzter Pausezeitauswirkung auf einen Mutatorprozess mit Zugriff darauf, wobei das genannte Verfahren Folgendes umfasst: Konfigurieren einer Schreibsperre zum Reagieren auf speicherorientierte Zugriffe des genannten Mutatorprozesses, die auf eine From-Instanz des genannten Speicherobjekts abzielen, und auf speicherorientierte Zugriffe des genannten Mutatorprozesses, die auf eine To-Instanz des genannten Speicherobjekts abzielen; inkrementelles Kopieren des genannten Speicherobjekts von der genannten From-Instanz zu der genannten To-Instanz; Senden, während des genannten inkrementellen Kopierens und in Reaktion auf einen ersten der genannten speicherorientierten Zugriffe, des genannten ersten speicherorientierten Zugriffs zur genannten From- und zur genannten To-Instanz in Reaktion auf eine Übereinstimmung zwischen einem Objektkennzeichner für den genannten ersten speicherorientierten Zugriff und dem Inhalt des genannten Kennzeichnerspeichers für teilweise relozierte Objekte.
  25. Verfahren nach Anspruch 24, bei dem die genannte Schreibsperrenkonfiguration das Aktualisieren eines Kennzeichnerspeichers für teilweise relozierte Objekte zum Kennzeichnen der genannten From-Instanz und der genannten To-Instanz umfasst.
  26. Verfahren nach Anspruch 24, ferner umfassend: Aufrechterhalten eines Teilkopiepositionsanzeigers zum Unterscheiden zwischen einem kopierten Teil und einem unkopierten Teil des genannten Speicherobjekts und Leiten des genannten zweiten speicherorientierten Zugriffs zu der genannten From-Instanz und nicht zu der genannten To-Instanz während des genannten inkrementellen Kopierens und in Reaktion auf einen zweiten der genannten speicherorientierten Zugriffe, die auf den genannten unkopierten Teil abzielen.
  27. Verfahren nach Anspruch 24, bei dem das genannte Senden von der genannten Schreibsperre oder Trap-Handler-Software in Reaktion auf ein Trap von der genannten Schreibsperre durchgeführt wird.
  28. Verfahren nach Anspruch 24, ferner umfassend: inkrementelles Aktualisieren von Zeigern zum genannten Speicherobjekt zum Verweisen auf die genannte To-Instanz anstatt auf die genannte From-Instanz und Senden, während des genannten inkrementellen Aktualisierens von Zeigern und in Reaktion auf einen dritten der genannten speicherorientierten Zugriffe, des genannten dritten speicherorientierten Zugriffs an die genannte From-Instanz und an die genannte To-Instanz.
  29. Verfahren nach Anspruch 28, ferner umfassend das Unterscheiden zwischen dem genannten inkrementellen Kopieren und dem genannten inkrementellen Aktualisieren mithilfe eines Relokationsmodusanzeiger, der von einem Garbage-Collection-Prozess aufrecht erhalten wird, der das genannte inkrementelle Kopieren und das genannte inkrementelle Aktualisieren von Zeigern durchführt.
  30. Verfahren nach Anspruch 28, ferner umfassend das Unterscheiden zwischen dem genannten inkrementellen Kopieren und dem genannten inkrementellen Aktualisieren mithilfe eines Teilkopiepositionsanzeigers, der von einem Garbage-Collection-Prozess aufrecht erhalten wird.
DE69828969T 1997-06-26 1998-06-25 Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit quellen- und zielinstanzen eines partiell relokierten objektes assoziiert ist Expired - Lifetime DE69828969T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US882796 1986-07-14
US08/882,796 US5873104A (en) 1997-06-26 1997-06-26 Bounded-pause time garbage collection system and method including write barrier associated with source and target instances of a partially relocated object
PCT/US1998/013620 WO1999000732A1 (en) 1997-06-26 1998-06-25 Bounded-pause time garbage collection system and method including write barrier associated with source and target instances of a partially relocated object

Publications (2)

Publication Number Publication Date
DE69828969D1 DE69828969D1 (de) 2005-03-17
DE69828969T2 true DE69828969T2 (de) 2006-04-13

Family

ID=25381348

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69828969T Expired - Lifetime DE69828969T2 (de) 1997-06-26 1998-06-25 Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit quellen- und zielinstanzen eines partiell relokierten objektes assoziiert ist

Country Status (6)

Country Link
US (1) US5873104A (de)
EP (1) EP0991998B1 (de)
JP (1) JP3881702B2 (de)
KR (1) KR20010020495A (de)
DE (1) DE69828969T2 (de)
WO (1) WO1999000732A1 (de)

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199075B1 (en) * 1997-05-30 2001-03-06 Sun Microsystems, Inc. Method and apparatus for generational garbage collection of a heap memory shared by multiple processors
US5987572A (en) * 1997-09-29 1999-11-16 Intel Corporation Method and apparatus employing a dynamic encryption interface between a processor and a memory
JP4177960B2 (ja) * 1997-12-19 2008-11-05 マイクロソフト コーポレーション 増分不要情報収集
US6065020A (en) * 1998-05-27 2000-05-16 Microsoft Corporation Dynamic adjustment of garbage collection
US6421689B1 (en) * 1998-06-30 2002-07-16 Oracle Corporation Moderately conservative, mostly copying 2 space garbage collector in the nursery of a generational memory manager
US6131191A (en) * 1998-07-21 2000-10-10 Intel Corporation Code implants for compilers
US6202208B1 (en) * 1998-09-29 2001-03-13 Nortel Networks Limited Patching environment for modifying a Java virtual machine and method
GB9825102D0 (en) 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
US6421739B1 (en) * 1999-01-30 2002-07-16 Nortel Networks Limited Fault-tolerant java virtual machine
GB9907280D0 (en) * 1999-03-31 1999-05-26 Philips Electronics Nv A method of scheduling garbage collection
US7096238B2 (en) * 1999-08-19 2006-08-22 Sun Microsystems, Inc. Dynamic feedback for determining collection-set size
US6427154B1 (en) * 1999-12-16 2002-07-30 International Business Machines Corporation Method of delaying space allocation for parallel copying garbage collection
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
US6738875B1 (en) * 2000-07-31 2004-05-18 Microsoft Corporation Efficient write-watch mechanism useful for garbage collection in a computer system
US6976254B2 (en) * 2001-11-28 2005-12-13 Esmertec Ag Inter-method control transfer for execution engines with memory constraints
JP3939975B2 (ja) * 2001-12-14 2007-07-04 松下電器産業株式会社 ガベージコレクション装置、ガベージコレクション方法及びガベージコレクションプログラム
US6928460B2 (en) * 2002-07-01 2005-08-09 Sun Microsystems, Inc. Method and apparatus for performing generational garbage collection in a segmented heap
US7539713B2 (en) 2002-11-05 2009-05-26 Sun Microsystems, Inc. Allocation of likely popular objects in the train algorithm
US7035884B2 (en) * 2002-11-05 2006-04-25 Sun Microsystems, Inc. Placement of allocation trains in the train algorithm
US6999979B2 (en) * 2002-11-05 2006-02-14 Sun Microsystems, Inc. Efficient encoding of references into a collection set
US7188129B2 (en) * 2002-11-15 2007-03-06 Sun Microsystems, Inc. Merging trains in a collector based on the train algorithm
US7209935B2 (en) * 2002-11-27 2007-04-24 Sun Microsystems, Inc. Avoiding remembered-set maintenance overhead for memory segments known to be in a collection set
US7085790B2 (en) * 2002-12-06 2006-08-01 Sun Microsystems, Inc. Advancing cars in trains managed by a collector based on the train algorithm
US7069280B2 (en) 2002-12-06 2006-06-27 Sun Microsystems, Inc. Collection-tick mechanism for a collector based on the train algorithm
US7143124B2 (en) 2002-12-06 2006-11-28 Sun Microsystems, Inc. Detection of dead regions during incremental collection
US7031990B2 (en) 2002-12-06 2006-04-18 Sun Microsystems, Inc. Combining external and intragenerational reference-processing in a garbage collector based on the train algorithm
US7024437B2 (en) * 2002-12-06 2006-04-04 Sun Microsystems, Inc. Better placement of objects reachable from special objects during collection based on the train algorithm
DE602004028121D1 (de) 2003-01-31 2010-08-26 Visto Corp Asynchrones echtzeit-abrufen von daten
US7069281B2 (en) 2003-02-24 2006-06-27 Sun Microsystems, Inc. Efficient collocation of evacuated objects in a copying garbage collector using variably filled local allocation buffers
US7146390B2 (en) 2003-02-24 2006-12-05 Sun Microsystems, Inc. Staging the processing of remembered-set entries as part of collection based on the train algorithm
US7062519B2 (en) * 2003-02-27 2006-06-13 Sun Microsystems, Inc. Incremental scanning of enormous objects to improve scheduling and pause-time behavior of garbage collection
US20040186863A1 (en) * 2003-03-21 2004-09-23 Garthwaite Alexander T. Elision of write barriers for stores whose values are in close proximity
US7089272B1 (en) 2003-06-18 2006-08-08 Sun Microsystems, Inc. Specializing write-barriers for objects in a garbage collected heap
US7149762B1 (en) 2003-08-20 2006-12-12 Sun Microsystems, Inc. Handling futile collections in the train algorithm through selective extension of the collection set
US7404182B1 (en) 2003-10-03 2008-07-22 Sun Microsystems, Inc. Deferring and combining write barriers for a garbage-collected heap
US7624137B2 (en) * 2004-01-05 2009-11-24 International Business Machines Corporation Method and apparatus for scheduling and performing garbage collection in a real-time system with guaranteed space bounds
US7702663B2 (en) * 2004-01-05 2010-04-20 International Business Machines Corporation Breaking read barrier to apply optimizations
KR100608606B1 (ko) * 2004-01-28 2006-08-03 삼성전자주식회사 적응형 가비지 컬렉션 방법 및 상기 방법을 수행하는 장치
US20050198088A1 (en) * 2004-03-03 2005-09-08 Sreenivas Subramoney Method and system for improving the concurrency and parallelism of mark-sweep-compact garbage collection
US8131955B2 (en) * 2004-04-15 2012-03-06 Microsoft Corporation Ephemeral garbage collection using a tracking mechanism on a card table to determine marked bundles
US7620943B1 (en) 2004-06-30 2009-11-17 Sun Microsystems, Inc. Using class properties to segregate objects in a generation managed by the train algorithm
US7676801B1 (en) 2004-08-31 2010-03-09 Sun Microsystems, Inc. Scanning of evacuated objects in a generation managed by the train algorithm
US7321909B1 (en) 2004-12-23 2008-01-22 Sun Microsystems, Inc. Method and apparatus for forwarding references to objects concurrently with space-incremental garbage collection
US20060271557A1 (en) * 2005-05-25 2006-11-30 Terracotta, Inc. Database Caching and Invalidation Based on Detected Database Updates
US7953773B2 (en) * 2005-07-15 2011-05-31 Oracle International Corporation System and method for deterministic garbage collection in a virtual machine environment
JP4769946B2 (ja) * 2007-02-05 2011-09-07 国立大学法人京都大学 メモリ管理方法、メモリ管理装置、及びメモリ管理プログラムが記録されている記録媒体
US9208081B1 (en) * 2007-11-30 2015-12-08 Oracle America, Inc. Concurrent object management
EP2361417B1 (de) * 2008-12-18 2022-02-16 BlackBerry Limited Verfahren und vorrichtung für inhaltsbewusste datenpartitionierung und datenentduplikation
US8452739B2 (en) * 2010-03-16 2013-05-28 Copiun, Inc. Highly scalable and distributed data de-duplication
US9135264B2 (en) * 2010-03-12 2015-09-15 Copiun, Inc. Distributed catalog, data store, and indexing
CN103229161B (zh) 2010-08-24 2016-01-20 科派恩股份有限公司 连续接入网关和去重数据缓存服务器
US9921959B2 (en) 2016-03-11 2018-03-20 Oracle International Corporation Efficient reference classification and quick memory reuse in a system that supports concurrent garbage collection
US10922081B2 (en) 2018-10-19 2021-02-16 Oracle International Corporation Conditional branch frame barrier
US11573894B2 (en) 2020-10-29 2023-02-07 Oracle International Corporation Tracking garbage collection states of references
US11875193B2 (en) 2021-03-25 2024-01-16 Oracle International Corporation Tracking frame states of call stack frames including colorless roots
US11573794B2 (en) 2021-03-25 2023-02-07 Oracle International Corporation Implementing state-based frame barriers to process colorless roots during concurrent execution
US11513954B2 (en) 2021-03-25 2022-11-29 Oracle International Corporation Consolidated and concurrent remapping and identification for colorless roots
US11789649B2 (en) 2021-04-22 2023-10-17 Nvidia Corporation Combined on-package and off-package memory system
US11507503B1 (en) * 2021-05-19 2022-11-22 Oracle International Corporation Write barrier for remembered set maintenance in generational Z garbage collector

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE387763B (sv) * 1975-10-23 1976-09-13 Ellemtel Utvecklings Ab Anordning vid ett datorminne for att mojliggora en successiv forflyttning under drift av ett ledigt minnesfelt
US4922414A (en) * 1982-12-17 1990-05-01 Symbolics Inc. Symbolic language data processing system
US4775932A (en) * 1984-07-31 1988-10-04 Texas Instruments Incorporated Computer memory system with parallel garbage collection independent from an associated user processor
JPS6393055A (ja) * 1986-10-07 1988-04-23 Fujitsu Ltd 実時間型ガ−ベジコレクシヨン支援装置
US4989134A (en) * 1987-03-20 1991-01-29 Hewlett-Packard Company Method and apparatus for enhancing data storage efficiency
US4807120A (en) * 1987-04-30 1989-02-21 Texas Instruments Incorporated Temporal garbage collector with indirection cells
US5136706A (en) * 1987-04-30 1992-08-04 Texas Instruments Incorporated Adaptive memory management system for collection of garbage in a digital computer
US4907151A (en) * 1988-09-30 1990-03-06 Digital Equipment Corporation System and method for garbage collection with ambiguous roots
US5088036A (en) * 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
US5321834A (en) * 1989-11-28 1994-06-14 Xerox Corporation Method and system for reclaiming unreferenced computer memory space
US5293614A (en) * 1991-04-08 1994-03-08 Texas Instruments Incorporated System and method for hard real-time garbage collection requiring a write barrier but no read barrier
US5218698A (en) * 1991-11-22 1993-06-08 Aerojet-General Corporation Garbage collection system for a symbolic digital processor
US5560003A (en) * 1992-12-21 1996-09-24 Iowa State University Research Foundation, Inc. System and hardware module for incremental real time garbage collection and memory management
US5687368A (en) * 1994-07-22 1997-11-11 Iowa State University Research Foundation, Inc. CPU-controlled garbage-collecting memory module
US5590332A (en) * 1995-01-13 1996-12-31 Baker; Henry G. Garbage collection, tail recursion and first-class continuations in stack-oriented languages

Also Published As

Publication number Publication date
EP0991998B1 (de) 2005-02-09
KR20010020495A (ko) 2001-03-15
EP0991998A1 (de) 2000-04-12
JP2002506550A (ja) 2002-02-26
WO1999000732A1 (en) 1999-01-07
US5873104A (en) 1999-02-16
JP3881702B2 (ja) 2007-02-14
DE69828969D1 (de) 2005-03-17

Similar Documents

Publication Publication Date Title
DE69828969T2 (de) Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit quellen- und zielinstanzen eines partiell relokierten objektes assoziiert ist
DE69825751T2 (de) Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit einer quelleninstanz eines partiell relokierten objektes assoziiert ist
US5857210A (en) Bounded-pause time garbage collection system and method including read and write barriers associated with an instance of a partially relocated object
DE69738101T2 (de) Verwaltung des Zugangs zu Objekten mit Hilfe von Referenzen mit drei Zuständen
DE69836796T2 (de) Datenverarbeiter mit lokalisierter gedächtnisreklamierung
DE60105611T2 (de) Erkennung von viren durch histogramme
DE60032694T2 (de) Speicherrückforderungsverfahren
DE69636761T2 (de) Speichern und wiederauffinden von geordneten schlüsselmengen in einem kompakten 0-kompletten baum
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE69932964T2 (de) Verfahren, System und Rechnerprogrammprodukt zur Initialisierung einer Datenstruktur beim ersten Gebrauch
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE19959758A1 (de) Bestimmung der Art und der Genauigkeit von lokalen Variablen bei vorhandenen Subroutinen
EP0914632A1 (de) Schreibschutzsystem und verfahren zum trapping von zeigerspeichern bei garbage-sammlungs-seitengrenzüberschreitung
EP1639475B1 (de) Prozessorarchitektur für exakte zeigeridentifizierung
DE60307527T2 (de) Tupleraumoperationen für eine feinkörnige Systemsteuerung
DE60318993T2 (de) Eingebettete Speicherbereinigung
DE10218905A1 (de) Verfahren und Vorrichtung zur Zugriffssteuerung in Wissensnetzen
Stanchina et al. Mark-sweep or copying? a" best of both worlds" algorithm and a hardware-supported real-time implementation
EP1530131B1 (de) Beschleunigtes Referenzfinden für eine automatische Speicherbereinigung (Garbage Collection)
KR100576904B1 (ko) 가비지수집페이지경계횡단포인터스토어를트랩하기위한기록배리어시스템및방법
WO2005093580A1 (de) Speicherbereinigung (garbage collection) für smart cards
Zhou et al. Garbage Collection Algorithms for Java-Based Prolog Engines
Brown et al. PMOS Revitalised
Stojanovic Automatic Memory Management in Java
O'Toole et al. Real-Time Replication GC: An Implementation Report

Legal Events

Date Code Title Description
8364 No opposition during term of opposition