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

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

Info

Publication number
DE69825751T2
DE69825751T2 DE69825751T DE69825751T DE69825751T2 DE 69825751 T2 DE69825751 T2 DE 69825751T2 DE 69825751 T DE69825751 T DE 69825751T DE 69825751 T DE69825751 T DE 69825751T DE 69825751 T2 DE69825751 T2 DE 69825751T2
Authority
DE
Germany
Prior art keywords
memory
instance
partially
barrier
write
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
DE69825751T
Other languages
English (en)
Other versions
DE69825751D1 (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
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE69825751D1 publication Critical patent/DE69825751D1/de
Publication of DE69825751T2 publication Critical patent/DE69825751T2/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
    • 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
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)
  • Stored Programmes (AREA)

Description

  • Hintergrund der Erfindung
  • Bereich der Erfindung
  • Die vorliegende Erfindung betrifft Speicherbereinigung und insbesondere Verfahren und Vorrichtungen zum Erleichtern von Speicherbereinigung mit begrenzter Pausezeit.
  • Beschreibung der verwandten Technik
  • Herkömmlicherweise liegt die Verantwortung für eine dynamische Zuordnung und Zuordnungsaufhebung von Speicher bei den meisten Programmiersprachen beim Programmierer. So wird beispielsweise in der Programmiersprache C Memory vom Freispeicher (Heap) durch die Malloc-Prozedur (oder ihre Varianten) zugeordnet. Bei einer gegebenen Zeigervariablen p hat die Ausführung von Maschinenanweisungen, die dem Statement p = malloc(sizeof(SomeStruct)) entsprechen, zur Folge, dass die Zeigervariable p auf neu zugeordneten Speicher (Storage) für ein Memory-Objekt einer Größe zeigt, die zum Darstellen einer SomeStruct Datenstruktur erforderlich ist. Nach der Benutzung kann die Zuordnung des vor der Zeigervariablen p identifizierten Memory-Objekts durch Aufrufen von free(p) aufgehoben oder freigegeben werden. Die Sprachen Pascal und C++ bieten analoge Einrichtungen für eine explizite Zuordnung und Zuordnungsaufhebung von Memory.
  • Dynamisch zugeordneter Speicher (Storage) wird leider unerreichbar, wenn keine Referenz, oder kein Zeiger, auf den Speicher in dem Satz von Root-Referenzpositionen für eine bestimmte Berechnung verbleibt. Memory-Objekte, die nicht mehr erreichbar, aber noch nicht freigegelegten sind, werden als Garbage bezeichnet. Ebenso kann die Zuordnung von Speicher, der mit einem Memory-Objekt assoziiert ist, aufgehoben werden, während er noch referenziert ist. In diesem Fall wurde eine dangling Reference erzeugt. Im Allgemeinen kann es schwierig sein, dynamischen Memory korrekt zu verwalten. In den meisten Programmiersprachen wird eine Heap-Zuordnung für Datenstrukturen benötigt, die den Vorgang überleben, mit dem sie kreiert wurden. Wenn diese Datenstrukturen zu weiteren Vorgängen oder Funktionen geleitet werden, dann ist es möglicherweise schwierig oder unmöglich für den Programmierer oder Compiler, den Moment zu ermitteln, an dem es sicher ist, die Zuordnung aufzuheben.
  • Aufgrund dieser Schwierigkeit kann Speicherbereinigung, d. h. die automatische Rückgewinnung von Heap-zugeordnetem Speicher nach seiner letzten Verwendung durch ein Programm ein attraktives alternatives Modell des dynamischen Memory-Management sein. Speicherbereinigung ist besonders für funktionale Sprachen wie JAVATM (JAVATM und Warenzeichen auf der Basis von JAVA sind Warenzeichen oder eingetragene Warenzeichen von Sun Microsystems, Inc. in den Vereinigten Staaten und anderen Ländern), Prolog, Lisp. Smalltalk, Scheme, Eiffel, Dylan, ML, Haskell, Miranda, Oberon usw. attraktiv, die gemeinsame Datennutzung, verzögerte Ausführung und im Allgemeinen weniger vorhersehbare Ausführungsreihenfolgen haben als die prozeduralen Sprachen (siehe allgemein, Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management. S. 1–41, Wiley (1996), wo Speicherbereinigung und klassische Algorithmen dafür beschrieben sind).
  • Drei klassische Speicherbereinigungsverfahren sind Referenzzählung, Mark-Sweep und Kopieren von Speicherreklamation. Das erste, Referenzzählung, basiert auf dem Führen einer Zahl für die Anzahl von Referenzen, z. B. Zeigern, auf jedes Memory-Objekt aus aktiven Memory-Objekten oder Root-Referenzpositionen. Wenn ein neues Memory-Objekt zugeordnet und ein Zeiger darauf zugewiesen sind, dann wird die Referenzzahl des Memory-Objekts auf eins gesetzt. Dann wird jedes Mal, wenn ein Zeiger auf das Memory-Objekt gesetzt wird, die Referenzzahl des Memory-Objekts inkrementiert. Wenn eine Referenz auf das Memory-Objekt gelöscht oder überschrieben wird, dann wird die Referenzzahl dekrementiert. Memory-Objekte mit einer Referenzzahl von null sind unerreichbar und können als Garbage bereinigt werden. Eine Referenzzahl-Speicherbereinigungsimplementation beinhaltet typischerweise ein zusätzliches Feld, die Reference Count (Referenzzahl) in jedem Memory-Objekt und hat Inkrementierungs- und Dekrementierungssupport im Rahmen von Funktionen wie neues Objekt, Objekt löschen und Zeiger aktualisieren.
  • Im Gegensatz dazu beinhalten Bereinigungsprotokollierverfahren das Durchlaufen von Referenzketten durch Memory, um aktuelle, d. h. referenzierbare Memory-Objekte zu identifizieren. Ein solches Bereinigungsprotokollierverfahren ist das Mark-Sweep-Verfahren, bei dem Referenzketten durch Memory durchlaufen werden, um aktuelle Memory-Objekte zu identifizieren und zu markieren. Unmarkierte Memory-Objekte sind Garbage und werden bereinigt und während einer separaten Sweep-Phase zum freien Pool zurückgebracht. Eine Mark-Sweep-Speicherbereinigungsimplementation beinhaltet typischerweise ein zusätzliches Feld, z. B. ein Mark-Bit, in jedem Memory-Objekt. Mark-Kompakt-Bereiniger arbeiten ergänzend zum traditionellen Mark-Sweep-Ansatz mit Verdichtung (Compaction). Bei Verdichtung werden aktuelle Objekte verschoben, um nützliche Fragmentierungsreduktionen zu erzielen. Auch bei Referenzzahlverfahren kann Verdichtung angewendet werden.
  • Bei einem weiteren Protokollierungsverfahren, der Kopierbereinigung (Copying Collection), wird Memory (oder ein Teil davon) in zwei Teilräume unterteilt, einen mit aktuellen Daten und einen mit alten Daten. Kopierspeicherbereinigung beginnt damit, dass die Rollen der beiden Teilräume umgekehrt werden. Der Kopierbereiniger durchläuft dann die aktuellen Objekte im alten Teilraum, FromSpace, und kopiert erreichbare Objekte in den neuen Teilraum, ToSpace. Wenn alle aktuellen Objekte im FromSpace durchlaufen und kopiert sind, dann gibt es im ToSpace ein Duplikat der Datenstrukturen. Im Wesentlichen säubert ein Kopierbereiniger aktuelle Objekte aus dem Garbage. Ein nützlicher Nebeneffekt der Kopierbereinigung ist, dass aktuelle Objekte in ToSpace verdichtet werden, so dass Fragmentierung reduziert wird.
  • Generationale Ansätze bauen auf den Beobachtungen auf, dass (1) Memory-Objekte gewöhnlich jung sterben und dass (2) Protokollierungsmethoden erhebliche Ressourcen auf das Durchlaufen, Kopieren oder Verschieben von vergleichsweise lange gelebten Objekten aufwenden. Generationale Speicherbereinigungssysteme unterteilen den Heap in zwei oder mehrere Generationen, trennen Objekte nach Alter und konzentrieren Bereinigungsaufwand (oder wenigstens stärkeren Bereinigungsaufwand) auf die jüngere(n) Generation(en). Da die jüngste Generation klein ist, können speicherbereinigungsbezogene Pausezeiten durchschnittlich kurz gehalten werden. Speicherbereinigung innerhalb einer Generation kann Kopier- oder Mark-Sweep-Bereinigung sein. Die Promotion von Memory-Objekten von einer jüngeren zu einer älteren Generation beinhaltet typischerweise Kopieren.
  • Aufgrund der Kosten für das Kopieren großer Objekte beinhalteten einige generationale Ansätze große Objektbereiche (siehe z. B. Ungar and Jackson, Tenuring Policies for Generation-based Storage Reclamation, ACM SIGPLAN Notices, 23 (11), S. 1–17 (1988), Ungar and Jackson, An Adaptive Tenuring Policy for Generation Scavengers, ACM Transactions on Programming Languages and Systems, 14 (1), S. 1–17 (1992)). Die Technik besteht typischerweise darin, ein großes Objekt in einen im generationalen Teil des Heap gespeicherten Header-Teil und einen im großen Objektbereich gespeicherten Textteil zu unterteilen. Die Header-Teile werden wie andere Objekte gesäubert, aber es werden keine Ressourcen auf das Kopieren der Textteile aufgewendet. Ungar und Jackson haben gefunden, dass Pausezeiten durch Zuordnen von 330 KB zu einem großen Objektbereich um einen Faktor von vier reduziert werden können.
  • Für interaktive oder Echtzeit-Anwendungen sind kurze Speicherbereinigungspausen ein wesentlicher Leistungsfaktor. Traditionelle Implementationen von Protokollierungsspeicherbereinigern unterbrechen periodisch die Ausführung von Anwendungsprogrammen, um Memory in Memory-Bereichen zu durchsuchen, die nicht mehr gebraucht werden. Leider benötigen harte Echtzeitsysteme Worst-Case-Garantien, dass Ergebnisse rechtzeitig errechnet werden. Selbst in reinen interaktiven Systemen muss die Pausezeit begrenzt und kurz sein. So genannte inkrementale Speicherbereinigungsmethoden versuchen, längere Pausen zu vermeiden, die durch Start- und Stoppreklamation verursacht werden, und stattdessen die Bereinigung mit Anwendungsprogrammzyklen zu verschachteln. Um dieses Ziel zu erreichen, muss ein inkrementaler Bereiniger kohärent Heap-Zugriffe durch den Bereiniger und das Anwendungsprogramm verwalten (häufig allgemeiner Mutator genannt). Parallel arbeitende Bereiniger, z. B. in einem Multiprozessor, haben ähnliche, aber höhere Feinkornsynchronisationsanforderungen.
  • Im Allgemeinen haben verschachtelt oder parallel arbeitende Verschiebungsbereiniger Multileser-Multischreiber-Synchronisationsprobleme. Es wurden sowohl Lese- als auch Schreibbarrierenmethoden angewendet, um einen Mutator daran zu hindern, Speicherbereinigung zu unterbrechen, indem er die Konnektivität des Memory-Objektreferenzierungsgraphs auf eine Weise ändert, die das Durchlaufen des Bereinigers stört (siehe z. B. Steele, Multiprocessing Compactifying Garbage Collection, Communications of the ACM, 18 (9), S. 495–508 (1975) (Schreibbarriere, Mark-Sweep-Compact Collection); Dijkstra et al., On-the fly Garbage Collection: An Exercise in Cooperation, Communications of the ACM 21 (11), S. 965–975 (1978) (Schreibbarriere); Kung & Song, An Efficient Parallel Garbage Collection System and its Correctness Proof, IEEE Symposium on Foundations of Computer Science, S. 120–131 (1977) (Schreibbarriere); Baker, List Processing in Real-time on a Serial Computer, Communications of the ACM, 21 (4), S. 280–93 (1978) (Lesebarriere, Kopierbereiniger); Brooks, Trading Data Space for Reduced Time and Code Space in Real-time Garbage Collection on Stock Hardwaare, in Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, Austin, Texas, S. 256–62 (1984) (Schreibbarriere, Kopierbereiniger); und Dawson, Improved Effectiveness from a Real-time Lisp Garbage Collector, Conference Record of the 1992 ACM Symposium on Lisp and Functional Programming, San Fransisco. Kalifornien, S. 159–67 (1982) (Schreibbarriere, Kopierbereiniger).
  • Die Symbolics 3600 bot Hardware-Lesebarrieren- und Schreibbarrierensupport für Kopierbereinigung nach Baker-Art und zum Abfangen von interenerationalen Zeigerspeicherungen (siehe Moon, Architecture of the Symbolics 3600, Proceedings of the 12th Annual International Symposium on Computer Architecture, S. 76–83 (1985)). Die MIT Lisp-Maschine und der TI-Explorer boten ebenfalls Hardware-Lesebarrierensupport für eine Kopierbereinigung nach Baker-Art. Nilsen und Schmidt beschreiben im US-Patent Nr. 5.60,003 ein speicherbereinigtes Memory-Modul, das Hardware-Lesebarrieren- und Schreibbarrieren implementiert.
  • Zusätzlich zur Grundaufgabe des Verwaltens von Mutator-Zugriffen, um Änderungen an der Verknüpfbarkeit des Memory-Objektreferenzierungsgraphs auf eine Weise zu verhindern, die ein Durchlaufen des Bereinigers stören würde, sollten Verschiebungsbereiniger mit begrenzter Pausezeit die erhebliche Zeitperiode angehen, die zum Verschieben eines großen und/oder populären Memory-Objekts benötigt wird. Ein Speicherbereiniger kann sicherstellen, dass Memory-Objekte innerhalb eines begrenzten Intervalls vollständig verschoben werden können, indem große Objekte, die mit dem begrenzten Intervall inkompatibel sind, auf einen großen Objektbereich relegiert werden, der mit einer verschiebungsfreien Methode bereinigt werden (siehe z. B. Ungar und Jackson, Tenuring Policies for Generation-based Storage Reclamation, ACM SIGPLAN Notices, 23 (11), S. 1–17 (1988)) oder der unbereinigt bleiben kann. Lazy- oder Inkremental-Kopieransätze werden jedoch bevorzugt.
  • Die Lösung von Baker bestand darin, ein zusätzliches Link-Wort in den Header von großen Objekten einzubauen. In einer FromSpace-Instanz des Objekts speicherte das Link-Wort eine Weiterleitungsadresse zu einer ToSpace-Instanz des Objektes. In der ToSpace-Instanz des Objektes speicherte das Link-Wort eine Rückwärtslink zu der FromSpace-Instanz. Wenn die Weiterleitungs- und die Rückwärtslink stehen, dann wurde das Objekt inkremental kopiert. Wie kleine Objekte, so wurden Felder des großen Objektes kopiert und auf Zeiger zurück in FromSpace-Objekte abgetastet, die noch nicht kopiert worden waren. Baker benutzte die abgetastete/unabgetastete Grenze, die von einer Speicherbereinigungsvariablen, Scan, definiert wurde, um Schreibzugriffe auf das teilkopierte große Objekt zu lenken. Die Kosten für das System von Baker, abgesehen von einem zusätzlichen Header-Wort, waren eine Software-Schreibbarriere für Schreibvorgänge in die ToSpace-Instanz des großen Objektes. Wenn die Adresse größer als Scan war, dann erfolgte der Schreibvorgang in der OldSpace-Instanz mit der Rückwärtslink; ansonsten erfolgte der Schreibvorgang in der NewSpace-Instanz.
  • Nilsen und Schmidt präsentierten eine Hardware-Lösung auf der Basis des Kopierbereinigers von Baker. Speziell stellten Nilsen und Schmidt ein speicherbereinigtes Memory-Modul bereit, in dem eine Hardware-Lesebarriere die Illusion gibt, dass die Bereinigung abgeschlossen ist. Ein Hardware-Arbiter in dem speicherbereinigten Memory- Modul bot eine Hardware-Lesebarriere des Baker-Typs und zusätzlich Lese- und Schreibbarrieren für Zugriffe auf einen bis dahin unkopierten Teil einer Objektinstanz in ToSpace. Das speicherbereinigte Memory-Modul führte Speicheradressregister. um Beginn und Ende des unkopierten Teils anzuzeigen. Lese- und Schreibzugriffe auf den unkopierten Teil wurden zur FromSpace-Instanz gerichtet.
  • Die US 5 293 614 offenbart ein weiteres System und Verfahren für eine harte Echtzeit-Speicherbereinigung, die eine Schreibbarriere erfordert und die Eigenschaften aufweist, die im Oberbegriff der unabhängigen Ansprüche definiert sind.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung ist in den beiliegenden Ansprüchen definiert. Man hat entdeckt, dass eine Schreibbarriere auf Speicher in ein teilweise verschobenes großes und/oder populäres Memory-Objekt Implementationen von Verschiebungsspeicherbereinigern mit begrenzter Pausezeit erleichtert, wie z. B. Kopierbereinigern, generationalen Bereinigern und Bereinigern mit Verdichtung. Teilweise verschobener Objektkennungsspeicher und darauf ansprechende Schreibbarriere ermöglichen eine Unterbrechung der Verschiebung von großen und/oder populären Memory-Objekten durch eine Speicherbereinigungsimplementation, um einem Mutatorprozess begrenzte Pausezeitgarantien zu geben.
  • Ein teilweise verschobener Objektkennungsspeicher mit „copy from" Kennungsspeicher, auf den Schreibbarrierenlogik zugreifen kann, folgt der Schreibbarrierenlogik, um die Einheitlichkeit zwischen FromSpace- und ToSpace-Instanzen eines teilweise verschobenen Memory-Objekts zu bewahren. In einigen Ausgestaltungen fängt die Schreibbarrierenlogik zu einem teilweise verschobenen Objekt-Trap-Handler ab, der die Einheitlichkeit wahrt. In anderen Ausgestaltungen, die einen „copy from" Kennungsspeicher beinhalten, auf den Schreibbarrierenlogik zugreifen kann, wahrt die Schreibbarriere selbst die Einheitlichkeit ohne Software-Trap-Handler-Overheads. Ein fakultativer „how far" (wie weit) Anzeigespeicher erleichtert die Unterscheidung, durch die Schreibbarrierenlogik oder durch den teilweise verschobenen Objekt-Trap-Handler, zwischen einem kopierten Teil und einem unkopierten Teil des teilweise verschobenen Memory-Objekts. Einige Ausgestaltungen können möglicherweise nicht zwischen kopierten und unkopierten Teilen des teilweise verschobenen Objekts unterscheiden. Ferner erlaubt es zwar der „Copy to" und der „Copy from" Kennungsspeicher, auf den die Schreibbarriere zugreifen kann, vorteilhafterweise, dass die Schreibbarrierenlogik Einheitlichkeit zwischen FromSpace- und ToSpace-Instanzen eines teilweise verschobenen Memory-Objekts ohne Software-Trap-Handler-Overhead wahrt, aber einige Ausgestaltungen können einen solchen Software-Trap-Handler beinhalten. Eine Reihe verschiedener alternativer Funktionalitätszuordnungen zwischen Schreibbarrierenlogik und einem teilweise verschobenen Objekt-Trap-Handler sind vorgesehen und fallen in den Umfang der Ansprüche.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird für die Fachperson nach Bezugnahme auf die Begleitzeichnungen besser verständlich, und ihre zahlreichen Aufgaben, Merkmale und Vorteile werden nach einer solchen Bezugnahme offensichtlich.
  • 1a und 1b (nachfolgend kollektiv 1 genannt) sind ein Blockdiagramm einer beispielhaften Ausgestaltung eines Hardware-Prozessors einer virtuellen Maschine, der Support für Speicherbereinigungsimplementationen mit begrenzter Pausezeit gemäß der vorliegenden Erfindung beinhaltet.
  • 2 veranschaulicht „Aufbau"-Beziehungen zwischen Software- und Hardware-Komponenten einer JAVA-Anwendungsumgebung mit Hardware-Prozessor (1) und Software-Komponenten einer beispielhaften virtuellen JAVA-Maschinenimplementation.
  • 3 illustriert mehrere mögliche Zusätze zum Hardware-Prozessor von 1.
  • 4a und 4b (nachfolgend kollektiv 4 genannt) veranschaulichen eine Ausgestaltung eines teilweise verschobenen Objektkennungsspeichers und eines beispielhaften Memory-Objektreferenzierungsgraphs gemäß einer Teilraum-Memory-Organisation für einen Kopierspeicherbereiniger vor dem Kopieren.
  • 5 veranschaulicht den teilweise verschobenen Objektkennungsspeicher und die Teilraum-Memory-Organisation von 4 beim Kopieren eines großen Objekts vom FromSpace auf den ToSpace.
  • 6 veranschaulicht Zugriffe eines Kopierbereinigungsprozesses und eines Mutatorprozesses auf FromSpace- und ToSpace-Teile eines bereinigten Memory-Bereiches, der ein teilweise verschobenes großes Objekt beinhaltet. 6 illustriert den Betrieb einer Schreibbarriere des Hardware-Prozessors von 1 in Verbindung mit dem teilweise verschobenen Objektkennungsspeicher der 4 und 5.
  • 7 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit einer Barriere für Speicherungen auf eine Copy-from-Instanz eines teilweise verschobenen Objektes und eines Trap-Handlers dafür.
  • 8 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit einer Hardware-Barriere für Speicherungen auf eine Copy-from- Instanz eines teilweise verschobenen Objekts und mit einem teilweise verschobenen Objektkennungsspeicher mit Copy-from- und Copy-to-Instanzkennungen. Die Ausgestaltung von 8 sendet selektiv Speicherdaten zu der Copy-from-Instanz und der Copy-to-Instanz des teilweise verschobenen Objekts rund.
  • 9 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit einer Hardware-Barriere für Speicherungen zu einer Copy-from-Instanz eines teilweise verschobenen Objekts und mit einem teilweise verschobenen Objektkennungsspeicher mit einer Copy-from-Instanzkennung, einer Copy-to-Instanzkennung und einer kopierten/unkopierten Grenzkennung. Die Ausgestaltung von 9 leitet oder sendet selektiv Speicherdaten je nach dem teilweisen Verschiebungszustand des teilweise verschobenen Objekts rund, um ein inkrementales Kopieren zu ermöglichen.
  • 10 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit Barrieren für Speicherungen auf die Copy-from- und die Copy-to-Instanzen eines teilweise verschobenen Objekts und mit einem teilweise verschobenen Objektkennungsspeicher mit Copy-from- und Copy-to-Instanzkennungen. Die Ausgestaltung von 10 ermöglicht sowohl inkrementales Kopieren als auch inkrementales Zeiger-Update.
  • 11 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit Barrieren für Speicherungen auf die Copy-from- und die Copy-to-Instanzen eines teilweise verschobenen Objekts und mit einem teilweise verschobenen Objektkennungsspeicher mit einer Copy-from-Instanzkennung, einer Copy-to-Instanzkennung, einer kopierten/unkopierten Grenzkennung und einem Speicherbereinigungsphasenindikator. Die Ausgestaltung von 11 leitet oder sendet selektiv Speicherdaten je nach dem teilweisen Verschiebungszustand des teilweise verschobenen Objekts und der Speicherbereinigungsphase rund, um sowohl inkrementales Kopieren als auch inkrementales Zeiger-Update zu ermöglichen.
  • 12 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit Barrieren für Ladungen auf eine Copy-from-Instanz eines teilweise verschobenen Objekts und für Speicherungen auf die Copy-from-Instanz und mit einem teilweise verschobenen Objektkennungsspeicher mit einer Copy-from-Instanzkennung, einem Speicherbereinigungsphasenindikator und einem teilweise verschobenen Objekt-Trap-Handler. Die Ausgestaltung von 12 leitet selektiv Speicherungen um oder sendet sie rund und leitet selektiv Ladungen um, um sowohl inkrementales Kopieren als auch inkrementales Zeiger-Update zu ermöglichen, und in einigen Variationen Überlappungen von Copy-from- und Copy-to-Instanzen.
  • 13 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit Barrieren für Ladungen von einer Copy-from-Instanz eines teilweise verschobenen Objektes und für Speicherungen auf die Copy-from-Instanz und mit einem teilweise verschobenen Objektkennungsspeicher mit einer Copy-from-Intanzkennung, einer Copy-to-Instanzkennung und einem Speicherbereinigungsphasenindikator. Die Ausgestaltung von 13 lenkt selektiv Speicherungen um oder sendet sie rund und lenkt selektiv Ladungen um, um sowohl inkrementales Kopieren als auch inkrementales Zeiger-Update zu ermöglichen.
  • 14 veranschaulicht eine Ausgestaltung eines Speicherbereinigungssystems mit begrenzter Pausezeit mit Barrieren für Ladungen von einer Copy-from-Instanz eines teilweise verschobenen Objektes und für Speicherungen auf die Copy-from-Instanz und mit einem teilweise verschobenen Objektkennungsspeicher mit einer Copy-from-Instanzkennung, einer Copy-to-Instanzkennung, einer kopierten/unkopierten Grenzkennung und einem Speicherbereinigungsphasenindikator. Die Ausgestaltung von 13 leitet selektiv Speicherungen um und leitet selektiv Ladungen um, um inkrementales Kopieren, inkrementales Zeiger-Update und Überlappungen von Copy-from- und Copy-to-Instanzen zu ermöglichen.
  • 15 veranschaulicht den Betrieb eines Speicherbereinigungssystems mit begrenzter Pausezeit, um Überlappungen von FromSpace- und ToSpace-Teilen eines teilweise verschobenen großen Objektes zuzulassen.
  • 16 veranschaulicht ein Objektreferenz-(objectref)Format gemäß einer Ausgestaltung der vorliegenden Erfindung.
  • 17A veranschaulicht ein Objektformat gemäß einer Ausgestaltung der vorliegenden Erfindung.
  • 17B veranschaulicht ein alternatives gehandhabtes Objektformat gemäß einer Ausgestaltung der vorliegenden Erfindung.
  • Gleiche Bezugszeichen in verschiedenen Zeichnungen bedeuten ähnliche oder identische Elemente.
  • BESCHREIBUNG DER BEVORZUGTEN AUSGESTALTUNG(EN)
  • Es folgt eine ausführliche Beschreibung der für am besten gehaltenen Art der Durchführung der Erfindung. Die Beschreibung soll die Erfindung illustrieren und ist nicht als sie begrenzend anzusehen.
  • Architektursupport für Implementationen von verschobenen Speicherbereinigern mit begrenzter Pausezeit beinhaltet Speicher zum Identifizieren von Positionen, von denen (und in einigen Ausgestaltungen, zu denen) ein großes und/oder populäres Memory-Objekt verschoben wird. Der hierin verwendete Begriff großes Objekt ist ein beliebiges Memory-Objekt mit einer solchen Größe, Struktur oder einem solchen Inhalt, dass die Verschiebung des kompletten Memory-Objekts, potentiell mit Updates von Referenzen darauf, unter ungünstigsten Bedingungen mit Begrenzte-Pausezeit-Garantien einer Speicherbereinigungsimplementation inkompatibel sein kann. Wie oben, wird in Ausgestaltungen gemäß der vorliegenden Erfindung ein großes Objekt mit unterschiedlichen Graden an Konservatismus operativ definiert. So können einige Ausgestaltungen beispielsweise einen Größenschwellenwert verwenden, während andere beim Berechnen eines großen Objekts Referenzzahlen benutzen können. Noch andere Ausgestaltungen, besonders solche, die im Wesentlichen auf Hardware basieren, können den hierin beschriebenen Architektursupport ohne Rücksicht auf die Größe des Memory-Objekts nutzen. Der hierin verwendete Begriff populäres Objekt ist ein beliebiges Memory-Objekt mit einer Referenzzahl, so dass die Verschiebung des Memory-Objekts, einschließlich Updates von Verweisen darauf, unter ungünstigsten Bedingungen mit Begrenzte-Pausezeit-Garantien einer Speicherbereinigungsimplementation inkompatibel sein können. Wie oben, so wird ein populäres Objekt in Ausgestaltungen gemäß der vorliegenden Erfindung mit unterschiedlichen Graden an Konservatismus operativ definiert.
  • Im Allgemeinen können Ausgestaltungen gemäß der vorliegenden Erfindung den hierin beschriebenen Architektursupport zum Verschieben von großen Objekten, populären Objekten, großen und populären Objekten, allen Objekten (einschließlich, aber nicht begrenzt auf, große(n) und/oder populäre(n) Objekte(n)) usw. verwenden. Ein solcher Architektursupport kann zwar in Hardware, Software oder einer Kombination aus Hardware und Software bereitgestellt werden, aber Ausgestaltungen, in denen Architektursupport im Wesentlichen in Hardware bereitgestellt wird, bieten typischerweise eine höhere Leistung und den Vorteil von reduzierten Memory-Anforderungen. Aus diesem Grund wird hierin eine beispielhafte Hardware-Prozessorausgestaltung beschrieben. Auf der Basis dieser Beschreibung wird die Fachperson jedoch alternative Ausgestaltungen erkennen können, die in den Umfang der nachfolgenden Ansprüche fallen.
  • Der hierin verwendete Begriff Verschiebungsspeicherbereiniger ist ein beliebiger Speicherbereiniger, der im Rahmen seines Betriebs Memory-Objekte verschiebt, einschließlich z. B. Kopierbereinigern, generationalen Bereinigern und Bereinigern, die Verdichtung oder Objektverschiebung zum Reduzieren von Fragmentierung und/oder zur Verbesserung der Lokalität bereitstellen. Echtzeit- oder Begrenzte-Pausezeit-Implementationen solcher Verschiebungsspeicherbereiniger werden typischerweise als Inkremental-Speicherbereinigungssoftwareprozess implementiert, dessen Berechnungen mit der Benutzerprozessaktivität verschachtelt sind. Die Fachperson wird jedoch parallel arbeitende Speicherbereinigungsimplementationen auf der Basis der hierin gegebenen Beschreibung erkennen. Ferner wird die Fachperson geeignete Modifikationen erkennen, einschließlich der Bereitstellung von Speicherkapazität zum Identifizieren mehrerer teilweise verschobener Objekte, um parallele Bereinigungsimplementationen zu unterstützen.
  • Ausgestaltung mit virtuellem JAVA-Maschinenanweisungsprozessor
  • 1 veranschaulicht eine exemplarische Hardware-Ausgestaltung eines virtuellen Maschinenanweisungsprozessors 100, nachfolgend Hardware-Prozessor 100 genannt, der Support für eine Verschiebungsspeicherbereinigung mit begrenzter Pausezeit gemäß der vorliegenden Erfindung beinhaltet und der von der Prozessorarchitektur unabhängige virtuelle JAVA-Maschinenanweisungen direkt ausführt. Die Leistung des Hardware-Prozessors 100 beim Ausführen von virtuellen Maschinenanweisungen ist gewöhnlich besser als bei High-End-CPUs wie dem Intel PENTIUM Mikroprozessor oder dem Sun Microsystems ULTRASPARC Prozessor (alle SPARC-Warenzeichen werden unter Lizenz verwendet und sind alle Warenzeichen oder eingetragene Warenzeichen von SPARC International, Inc. in den Vereinigten Staaten und anderen Ländern. Produkte, die SPARC-Warenzeichen tragen, basieren auf einer Architektur, die von Sun Microsystems, Inc. entwickelt wurde. PENTIUM ist ein Warenzeichen der Intel Corp. aus Sunnyvale, CA), die dieselben virtuellen Maschinenanweisungen mit einem Software-JAVA-Interpreter oder einem JAVA-JIT (just-in-time) Compiler interpretieren. Darüber hinaus ist der Hardware-Prozessor kostenarm und hat eine geringe Leistungsaufnahme. Infolgedessen ist der Hardware-Prozessor 100 für portable Anwendungen gut geeignet.
  • Da die Implementation des virtuellen JAVA-Maschinenanweisungsprozessors im Hardware-Prozessor 100 im Wesentlichen in Hardware vorliegt, können 25–50 KB Memory Storage, z. B. Festwertspeicher oder Arbeitsspeicher, die sonst ein Software-Interpreter benötigen wurde, eliminert oder alternativ zugeordnet werden. Hardware- Support für Speicherbereinigung bietet weitere Vorteile für eine virtuelle JAVA-Maschinenimplementation mit begrenztem Memory. indem Inline-Code für Speicherbereinigung reduziert wird (z. B. vom Compiler gelieferter Lese- und/oder Schreibbarrierensupport), indem eine verbesserte Auslastung von begrenztem Memory erleichtert oder indem Speicherbereinigungsoverheads und Pausezeiten reduziert werden. In Umgebungen, bei denen die Kosten eines großen Memory zu hoch sind, wie z. B. bei einem Internet-Chip für Netzwerkgeräte, einem Zellulartelefonprozessor, anderen Telekommunikations-ICs oder anderen kostenarmen Niedrigleistungsanwendungen wie eingebetteten Prozessoren und portablen Geräten, ist der Hardware-Prozessor 100 von Vorteil.
  • Selbst in Umgebungen, wo großer Memory möglich ist, reduziert Hardware-Support für Speicherbereinigung Overheads in Verbindung mit Barrierenausführungen, erleichtert eine verbesserte Memory-Auslastung und reduziert Pausezeiten für Verschiebungsspeicherbereinigungsimplementationen. Insbesondere bietet der Hardware-Prozessor 100 Vorteile für Speicherbereinigungsverfahren und -implementationen im Zusammenhang mit einer beispielhaften virtuellen JAVA-Maschinenimplementation. Auf der Basis der Beschreibung hierin wird die Fachperson jedoch Variationen für andere virtuelle JAVA-Maschinenimplementationen, z. B. interpretierte und JIT-Compiler-Implementationen, sowie für andere virtuelle Nicht-JAVA-Maschinenimplementationen erkennen.
  • Der hierin verwendete Begriff virtuelle Maschine ist eine abstrakte Rechenmaschine, die, wie eine echte Rechenmaschine. einen Anweisungssatz hat und verschiedene Memory-Bereiche benutzt. Eine virtuelle Maschinenspezifikation definiert einen Satz von von der Prozessorarchitektur unabhängigen virtuellen Maschinenanweisungen, die von einer virtuellen Maschinenimplementation ausgeführt werden können. Im Allgemeinen kann eine virtuelle Maschinenimplementation in Hardware (z. B. im Falle des Hardware-Prozessors 100), in Software (z. B. im Falle von interpretierten und JIT-Compiler-Implementationen) oder in Hardware und Software ausgeführt werden. Jede virtuelle Maschinenanweisung definiert einen spezifischen Vorgang, der durchgeführt werden soll. Die virtuelle Maschine braucht die Computersprache, die zum Erzeugen von virtuellen Maschinenanweisungen verwendet wird, oder die zugrunde liegende Implementation der virtuellen Maschine nicht zu verstehen. Es braucht lediglich ein bestimmtes Format für virtuelle Maschinenanweisungen verstanden zu werden. In einer beispielhafen Ausgestaltung sind die virtuellen Maschinenanweisungen virtuelle JAVA-Maschinenanweisungen. Jede virtuelle JAVA-Maschinenanweisung beinhaltet ein oder mehrere Bytes, die Anweisungen codieren, die Informationen, Operanden und andere benötigte Informationen identifizieren.
  • In dieser Ausgestaltung verarbeitet der Hardware-Prozessor 100 (1) die virtuellen JAVA-Maschinenanweisungen, die Bytecodes beinhalten. Der Hardware-Prozessor 100 führt die meisten der Bytecodes direkt aus. Die Ausführung von einigen der Bytecodes erfolgt jedoch über Microcode. Lindholm & Yellin, The JAVATM Virtual Machine Specification (Addison-Wesley, 1996), ISBN 0-201-63452-X (hiermit in seiner Gesamtheit durch Bezugnahme eingeschlossen) beinhaltet einen beispielhaften Satz von virtuellen JAVA-Maschinenanweisungen. Der besondere Satz von virtuellen Maschinenanweisungen, die von einem Hardware-Prozessor 100 unterstützt werden, ist kein wesentlicher Aspekt der vorliegenden Erfindung. Die Fachperson kann die Erfindung jedoch im Hinblick auf die virtuellen Maschinenanweisungen für einen bestimmten Satz von virtuellen Maschinenanweisungen oder Veränderungen der virtuellen JAVA-Maschinenspezifikation modifizieren.
  • In einer Ausgestaltung beinhaltet der Hardware-Prozessor 100 einen E/A-Bus und eine Memory-Schnittstelleneinheit 110, eine Anweisungs-Cache-Einheit 120 mit Anweisungs-Cache 125. eine Anweisungs-Decodiereinheit 130 mit Non-quick-zu-quick-Translator-Cache 131, eine vereinheitlichte Ausführungseinheit 140, eine Stapelmanagementeinheit 150 mit Stapel-Cache 155, eine Daten-Cache-Einheit 160 mit Daten-Cache 165 und eine Programmzähler- und Trap-Steuerlogik 170. Support für die hierin beschriebenen Speicherbereinigungsmerkmale liegt vornehmlich in der Ganzzahleneinheit 142 und dem Register 144 der Ausführungseinheit 140, mit etwas zusätzlichem Support in der Programmzähler- und Trap-Steuerlogik 170 (einschließlich z. B. Support zum Zwingen des Programmzählers zu einer nächsten virtuellen JAVA-Maschinenanweisung nach einer Abfangspeicherung). Die einzelnen Einheiten werden nachfolgend beschrieben. Darüber hinaus wird eine exemplarische Ausgestaltung des Hardware-Prozessors 100 ausführlicher in der am 31. Juli 1997 veröffentlichten PCT WO 9727536 (internationale Anmeldung Nr. PCT/US97/01221) beschrieben.
  • 2 veranschaulicht eine „Aufbau"-Beziehung zwischen Software- und Hardware-Komponenten einer JAVA-Anwendungsumgebung wie z. B. einer Anwendungsumgebung, die teilweise auf dem Hardware-Prozessor 100 (1) definiert und teilweise darauf ausgeführt wird. Die JAVA-Anwendungs-/Applet-Software 210 nutzt Software-Komponenten, die eine Applet/Anwendungsprogrammierschnittstelle (220) definiert, die Folgendes beinhaltet: Software-Komponenten für AWT-Klassen 241, Net- und E/A-Klassen 242 und JAVA OS Windows 243. JAVA OS Grafik 248, TCP 244, NFS 245, UDP 246, IP 247, Ethernet 222, Tastatur 249 und Maus 221, die in einer Ausgestaltung JAVA-Bytecodes beinhalten. In der Ausgestaltung von 2 beinhalten die Software-Komponenten JAVA OS Graphik 248 und Ethernet 222 erweiterte Bytecodes über diejenigen hinaus, die von der Baseline JAVA Virtual Machine Specification definiert werden. Komponenten einer eingebetteten Anwendungsprogrammierschnittstelle (EAPI) 230 beinhalten Grundklassen 231 sowie Hardware- und Software-Komponenten der virtuellen JAVA-Maschinenimplementation 250 gemäß der JAVA Virtual Machine Specification.
  • Die virtuelle JAVA-Maschinenimplementation 250 beinhaltet den Hardware-Prozessor 100 sowie darauf ablauffähigen Trap-Code zum Beurteilen von virtuellen JAVA-Maschinenanweisungen. Darüber hinaus beinhaltet die virtuelle JAVA-Maschinenimplementation 250 Hardware-Support für erweiterte Bytecodes (einschließlich z. B. Zeigerspeicher-Bytecodes und Memory-Zugriffsbarrieren, die nachfolgend in Zusammenhang mit Speicherbereinigung beschrieben werden); Software für Class-Loader 252, Bytecode-Verifizierer 253, Thread-Manager 354 und Speicherbereinigung 251 sowie Microkernel 255. Die virtuelle JAVA-Maschinenimplementation 250 beinhaltet einen Teil 250a gemäß der JAVA Virtual Machine Specification sowie implementationsabhängige Teile. Die JAVA Virtual Machine Specification gibt zwar die Bereitstellung von Speicherbereinigung vor, aber das jeweils verwendete Speicherbereinigungsverfahren ist implementationsabhängig.
  • Architekturmerkmale für Speicherbereinigung, die hierin im Zusammenhang mit einer beispielhaften Hardware-Prozessor 100 Ausgestaltung der virtuellen JAVA-Maschinenimplementation 250 beschrieben sind, sind besonders für generationale Speicherbereinigungsmethoden adaptiert. Auf der Basis dieser Beschreibung wird die Fachperson jedoch die Anwendung von Begrenzte-Pausezeit-Support der vorliegenden Erfindung zum Verschieben von Bereinigern im Allgemeinen erkennen, einschließlich z. B. nicht-generationaler Bereinigerimplementationen, inkrementaler Mark-Compact-Bereinigern, Kopierbereinigern usw.
  • 3 illustriert mehrere mögliche Zusätze zum Hardware-Prozessor 100, um ein komplizierteres System zu erstellen. Schaltungen, die beliebige der gezeigten acht Funktionen unterstützen, d. h. NTSC-Encoder 501, MPEG 502, Ethernet-Controller 503, VIS 504, ISDN 505, E/A-Controller 506, ATM-Assembly/Reassembly 507 und Radio-Link 508 können auf demselben Chip integriert werden wie der erfindungsgemäße Hardware-Prozessor 100.
  • Darüber hinaus wird die Fachperson eine Reihe verschiedener Computer-Systeme mit dem Hardware-Prozessor 100 erkennen, einschließlich Ausgestaltungen des Hardware-Prozessors 100 mit beliebigen der oben beschriebenen Zusatzschaltungen. Eine exemplarische Computersystemausgestaltung beinhaltet physikalischen Memory Storage (z. B RAM und/oder ROM), rechnerlesbare Media-Access-Geräte (z. B. Platte, CD-ROM, Band und/oder Memory-Technik auf der Basis von rechnerlesbaren Media-Access-Geräten usw.), Ein-/Ausgabegeräteschnittstellen (z. B. Schnittstellen für Tastatur und/oder Zeigergeräte, für Display-Geräte usw.) und Kommunikationsgeräte und/oder -schnittstellen. Geeignete Kommunikationsgeräte und/oder -schnittstellen sind u. a. solche für netzwerk- oder telefoniegestützte Kommunikationen, für die Verbindung mit Telekommunikationsnetzen einschließlich drahtgebundenen und/oder drahtlosen Teilen eines öffentlichen Wählnetzes, eines Privatnetzes usw. In einigen Ausgestaltungen der vorliegenden Erfindung werden Anweisungsströme (wie z. B. JAVA-Bytecodes) zur Ausführung durch den Hardware-Prozessor 100 über solche Kommunikationsgeräte oder -schnittstellen gesendet und/oder empfangen.
  • Architektursupport für Speicherbereinigung
  • Der Hardware-Prozessor 100 bietet Hardware-Support für eine Reihe verschiedener Speicherbereinigungsverfahren einschließlich Verschiebungsbereinigungsmethoden, die als darauf ablauffähige Speicherbereinigungssoftware implementiert werden. Insbesondere beinhaltet der Hardware-Prozessor 100 einen teilweise verschobenen Objektkennungsspeicher und Barrierensupport. In einigen Ausgestaltungen beinhaltet der Barrierensupport Schreibbarrierensupport für vom Programmierer wählbare Speicherfilterung und/oder Support für Ausführungszeitauflösung von Speicher-Bytecodes zu zeigerspezifischen Bytecodes, um Zeigerspeicher-Trapping zu erleichtern.
  • Teilweise verschobener Obiektkennungsspeicher
  • 4A veranschaulicht eine Ausgestaltung eines teilweise verschobenen Objektkennungsspeichers 410 einschließlich From-Feld 411, To-Feld 412 und Howfar-Feld 413. 4B zeigt FromSpace 420 und ToSpace 430 Teile eines Memory Storage gemäß einem Kopierbereinigungsverfahren. In einer generationalen Bereinigerimplementation können die Teile FromSpace 420 und ToSpace 430 Teilräume einer einzelnen Generation oder Teile von jeweils jungen bzw. alten Generationsräumen sein. Alternativ können die Teile FromSpace 420 und ToSpace 430 Teilräume in einem nicht generationalen Bereinigungsraum sein. Ferner können die Teile FromSpace 420 und ToSpace 430 einander überlappen, können individuell aneinander grenzend oder nicht aneinander grenzend sein, brauchen nicht unbedingt von fester Größe zu sein oder feste Positionen im Memory Storage zu haben. Darüber hinaus werden in einigen Ausgestaltungen mehrere FromSpace- und To-Space-Teile unterstützt, mit geeigneten Modifikationen an teilweise verschobenem Objektkennungsspeicher 410 und an den hierin beschriebenen Barrieren. 4B veranschaulicht einen ersten Referenzierungszustand von aktuellen Memory-Objekten A, B, C und dem großen Objekt 450 vor dem Kopieren in den ToSpace 430. Root-Zeigersatz 440 ist für jeden Root-Zeigersatz in die Referenzierungsstruktur repräsentativ, z. B. einschließlich Zeigern, die von Operandenstapel- und/oder Lokalvariablenspeichereinträgen stammen, die im Stapel-Cache 155 repräsentiert sind.
  • 5 veranschaulicht einen zweiten Referenzierungszustand eines teilweise verschobenen Objektkennungsspeichers 410, FromSpace 420 und ToSpace 430 bei der Unterbrechung der Verschiebung eines großen Objekts 450. Aktuelle Memory-Objekte A und B wurden auf entsprechende Instanzen A' und B' im ToSpace 430 kopiert. Nach der Unterbrechung des Kopierens beinhaltet das große Objekt 450 einen kopierten Teil 551 und einen nicht vollständig kopierten Teil 552. Inhalt des kopierten Teils 551 des großen Objekts 450 wurde auf einen entsprechenden Teil 551a einer ToSpace 430 Instanz des großen Objekts 450 kopiert. Der ToSpace 430 Speicher für den restlichen nicht vollständig kopierten Teil des großen Objekts 450 ist als Teil 552a dargestellt. Das From-Feld 411 identifiziert das große Objekt 450 im FromSpace 420, das To-Feld 412 identifiziert die entsprechende teilweise verschobene Instanz 450a des großen Objekts 450, und das Howfar-Feld 413 identifiziert eine Grenze zwischen dem kopierten Teil 551 und dem nicht vollständig kopierten Teil 552 des großen Objekts 450. Ein überlappendes Kopierrichtungsfeld (nicht dargestellt) ist fakultativ. In einer Ausgestaltung beinhaltet ein solches Kopierrichtungsfeld ein Kopierrichtungsbit, dessen Zustand eine Vorwärts- oder Rückwärtsrichtung zum Kopieren von überlappten FromSpace- und ToSpace-Instanzen beinhaltet. In anderen Ausgestaltungen wird die Kopierrichtung von den relativen Werten des From-Feldes 411 und des To-Feldes 412 abgeleitet, wie die Fachperson verstehen wird.
  • Das Howfar-Feld 413 zeit den Fortschritt des Kopierens des großen Objekts an und/oder aktiviert Schreibbarrierenhardware und einen teilweise verschobenen Objekt-Trap-Handler, um auf geeignete Weise Mutatorzugriffe auf ein teilweise kopiertes großes Objekt zu handhaben. In der Ausgestaltung von 5 zeigt das Howfar-Feld 413 die Adresse im Memory der Grenze zwischen dem kopierten Teil 551 und dem unkopierten Teil 552 an. Trotzdem wird die Fachperson auf der Basis der vorliegenden Beschreibung erkennen, dass eine Reihe verschiedener geeigneter alternativer Codierungen möglich sind, wie z. B. ein Index weg von der durch das From-Feld 411 angezeigten Speicherposition, eine Anzeige einer entsprechenden Grenze in der ToSpace-Instanz 550a des großen Objekts 450 usw. Das Howfar-Feld 413 codiert eine beliebige solche geeignete Anzeige.
  • 6 zeigt den teilweise verschobenen Objektkennungsspeicher 410 im Zusammenhang mit dem Mutatorprozess 610 und dem Speicherbereinigerprozess 620. In der Ausgestaltung von 6 sind der Mutatorprozess 610 und der Speicherbereinigungsprozess 620 jeweils durch virtuelle JAVA-Maschinenanweisungen definiert, die vom Hardware-Prozessor 100 ausgeführt werden können. Der Speicherbereinigungsprozess 620 beinhaltet einen beliebigen Verschiebungsbereiniger. Die nachfolgende Beschreibung bezieht sich zwar auf den oben mit Bezug auf 5 beschriebenen Teilraum-Kopierbereiniger, aber die Fachperson wird die Anwendbarkeit auf andere Verschiebungsbereiniger erkennen. Im Verlaufe des Kopierens des großen Objekts 450 vom FromSpace 420 auf den ToSpace 430 liest der Speicherbereinigungsprozess 620 vom bereinigten Raum 630 und schreibt darauf.
  • In einer Ausgestaltung aktualisiert der Speicherbereinigungsprozess 620 das From-Feld 411 und das To-Feld 412 zu Beginn des großen Objekts 450 und kopiert und aktualisiert das Howfar-Feld 413 während eines solchen Kopierens, so dass nach einer Unterbrechung durch den Mutatorprozess 610 das Howfar-Feld 413 die Grenze zwischen dem kopierten Teil 551 und dem unkopierten Teil 552 anzeigt. In Ausgestaltungen für eine parallele Ausführung von Mutatorprozess 610 und Speicherbereinigerprozess 620 (z. B. in einem Multiprozessor) kann das Howfar-Feld 413 gesperrt werden und die Fachperson wird geeignete Verfahren hierfür erkennen. Alternative Ausgestaltungen können bei Bedarf auf inkrementales Aktualisieren des Howfar-Felds 413 zu Gunsten eines Updates nach einer Unterbrechung verzichten.
  • Der Mutatorprozess 610 liest von dem Memory und schreibt darauf, der den bereinigten Raum 630 beinhaltet. In einer Ausgestaltung beinhaltet der Hardware-Prozessor 100 Support der Ganzzahleneinheit 142 für eine Barriere 660. die Objektreferenzierinformationen (z. B. objectref) auf Inhalt des From-Feldes 411, des To-Feldes 412 oder beide vergleicht. Eine Übereinstimmung mit dem Inhalt des From-Feldes 411 zeigt an, dass das referenzierte Objekt die FromSpace 420 Instanz des teilweise verschobenen großen Objekts 450 ist. Eine Übereinstimmung mit Inhalt des To-Feldes 412 zeigt an, dass das referenzierte Objekt die teilweise kopierte ToSpace 430 Instanz 450a ist. In einigen Ausgestaltungen wird die Beurteilung des jeweiligen Feldversatzes in das referenzierte Objekt mit Inhalt des Howfar-Feldes 413 verglichen, um die Handhabung der Barriere 660 von kopierten und unkopierten Teilen des referenzierten Objekts zu verfeinern.
  • In verschiedenen, nachfolgend ausführlicher beschriebenen Ausgestaltungen beinhaltet die Barriere 660 Schreibbarrierensupport, der auf teilweise verschobenen Objektkennungsspeicher 410 anspricht. In einigen Ausgestaltungen beinhaltet die Barriere 660 auch Lesebarrierensupport, der auf teilweise verschobenen Objektkennungsspeicher 410 anspricht. In einigen Ausgestaltungen beinhaltet die Barriere 660 Hardware-Lese- und/oder -Schreibbarrierensupport für Trapping zu einer teilweise verschobenen Objekt-Trap-Handler-Software, die den Trapping-Zugriff handhabt (z. B. durch Rundsenden eines Schreibzugriffs, Umleiten eines Schreibzugriffs, Umleiten eines Lesezugriffs oder Zulassen, dass ein Zugriff normal beendet wird). In anderen Ausgestaltungen bietet eine Hardware-Lese- und/oder -Schreibbarriere selbst eine solche geeignete Handhabung ohne Software-Trap-Handler-Overhead.
  • In einigen Ausgestaltungen ist eine Begrenzte-Pausezeit-Verschiebung durch Elemente der Barriere 660 vorgesehen, die ein inkrementales Kopieren eines großen und/oder populären Objektes zulässt, wobei Zeiger-Updates darauf über einen Objekt-Referenzier-Handle erfolgen. In solchen Ausgestaltungen erfolgen Zeiger-Updates selbst auf populäre Objekte trivial durch Aktualisieren eines einzigen Zeigers, d. h. des Objekt-Referenzier-Handle. In anderen Ausgestaltungen beinhaltet Begrenzte-Pausezeit-Verschiebung durch Elemente der Barriere 660 Support für inkrementales Aktualisieren von Zeigern auf ein populäres, und möglicherweise großes, Objekt. Der hierin verwendete Begriff Begrenzte-Pausezeit-Verschiebung beinhaltet sowohl Kopier- als auch Zeiger-Update. Die Fachperson wird die Anwendbarkeit der hierin beschriebenen Ausgestaltungen auf Begrenzte-Pausezeit-Verschiebung von großen Objekten, auf Begrenzte-Pausezeit-Verschiebung von populären Objekten und Begrenzte-Pausezeit-Verschiebung auf große, populäre Objekte erkennen. Eine gehandhabte und ungehandhabte Objektreferenzierung wird nachfolgend ausführlicher beschrieben.
  • Je nach der/den Speicherbereinigungsmethode(n), die von einer bestimmten Ausgestaltung des Hardware-Prozessors 100 unterstützt wird/werden, kann Schreib- und/oder Lesebarrierensupport vorgesehen werden, um zu verhindern, dass der Mutatorprozess 610 den Speicherbereinigerprozess 620 stört, indem er die Konnektivität des Memory-Objektreferenzierungsgraphs auf eine Weise ändert, die das Durchlaufen des Bereinigers stört. In einer Ausgestaltung des Hardware-Prozessors 100 sind beispielsweise vom Programmierer wählbare Hardware-Schreibbarrieren für intergenerationale Zeigerspeicherungen, für alle Zeigerspeicherungen und für alle Speicherungen (einschließlich Support für gefilterte Barrierenvarianten von allen) vorgesehen.
  • „GENERATIONSISOLATIONSSYSTEM UND VERFAHREN ZUR SPEICHERBEREINIGUNG"
  • In einer Ausgestaltung der Barriere 660 ist Unterstützung für solche zusätzlichen Barrieren mit der oben beschriebenen Barriere für Speicherungen in einem teilweise verschobenen großen Objekt integriert.
  • In Ausgestaltungen gemäß 1 beinhaltet ein teilweise verschobener Objekt-Trap-Handler virtuelle JAVA-Maschinenanweisungs-Bytecodes, die auf dem Hardware-Prozessor 100 ablaufen können und die vom Programmzähler und der Trap-Steuerlogik 170 eingeleitet werden. Speicherbereinigungstraps, einschließlich z. B. einem teilweise verschobenen Objekt-Trap, werden ausgelöst, bevor der Trapping-Schreibvorgang selbst beurteilt wird. Daher emuliert der teilweise verschobene Objekt-Trap-Handler 650, um zu verhindern, dass der Prozessor unendlich abfängt, den Trapping-Schreibvorgang zusammen mit den zusätzlichen speicherbereinigungsbezogenen Funktionen. In einer Ausgestaltung zwingt dann die Programmzähler- und Trap-Steuerlogik 170 den Programmzähler zur nächsten virtuellen JAVA-Maschinenanweisung nach dem Trapping-Schreibvorgang. Auf der Basis der nachfolgenden ausführlicheren Beschreibung wird die Fachperson eine Reihe verschiedener gültiger Verhaltensweisen für einen teilweise verschobenen Objekt-Trap-Handler je nach den erzwungenen Einheitlichkeitsrichtlinien erkennen.
  • Die Speicherbereinigung wurde zwar oben allgemein mit Bezug auf die illustrative Ausgestaltung von 6 eines teilweise verschobenen Objektkennungsspeichers 410 mit From-Feld 411, To-Feld 412, Howfar-Feld 413 und im Zusammenhang mit einer Barriere 660 beschrieben, die potentiell einen teilweise verschobenen Objekt-Trap-Handler beinhaltet, aber es sind auch verschiedene alternative Ausgestaltungen geeignet. In vielen dieser alternativen Ausgestaltungen kann ein teilweise verschobener Objekt-Trap-Handler wegfallen und Mutatorprozess-Zugriffe können durch Hardware-Barrierensupport ordnungsgemäß gehandhabt werden, so dass Overhead in Verbindung mit einem Trap-Handler reduziert wird. Auf der Basis der nachfolgenden Beschreibung beispielhafter Ausgestaltungen wird die Fachperson eine Reihe verschiedener zusätzlicher Kombinationen und Variationen erkennen, die in den Umfang der Ansprüche fallen.
  • Schreibbarriere, die mit Copy-From-Instunzkennungsspeicherung assoziiert ist
  • 7 veranschaulicht eine Ausgestaltung mit einem Copy-From-Registerfeld mit assoziierter Schreibbarriere. Insbesondere beinhaltet die Ausgestaltung von 7 das From-Feld 411 des teilweise verschobenen Objektkennungsspeichers 410 (siehe 4), die Hardware-Schreibbarriere 740 und den teilweise verschobenen Objekt-Trap-Handler 750. In der Ausgestaltung von 7 ist das From-Feld 411 in Registern 144 des Hardware-Prozessors 100 repräsentiert. Mutatorprozess 610, Speicherbereinigungsprozess 620 und teilweise verschobener Objekt-Trap-Handler 650 beinhalten Software, die auf dem Hardware-Prozessor 100 ablaufen kann. Diese Ausgestaltung erleichtert das inkrementale Kopieren großer Objekte. Ohne zusätzlichen Support ist diese Ausgestaltung jedoch nicht für ein inkrementales Update von großen Zahlen von Zeigern auf die ToSpace 430 Instanz eines populären verschobenen Objektes geeignet. Trotzdem reduziert eine solche Ausgestaltung für Speicherbereinigungssysteme, in denen Objekte beispielsweise über Handles referenziert werden, wie unten mit Bezug auf 17 beschrieben wird, Hardware-Anforderungen und ist für eine Begrenzte-Pausezeit-Verschiebung geeignet, da das Aktualisieren eines einzigen Handles auf die ToSpace 430 Instanz trivial sein kann.
  • Der Mutatorprozess 610 macht Lese- und Schreibzugriffe von und zu dem bereinigten Raum 630. Lesezugriffe bleiben durch Speicherbereinigungssupport unbetroffen. Schreibzugriffe werden jedoch von der Hardware-Schriebbarriere 740 selektiv abgefangen. Die Hardware-Schreibbarriere 740 löst den teilweise verschobenen Objekt-Trap-Handler 750 als Reaktion auf eine Übereinstimmung zwischen dem Inhalt des From-Feldes 411 und dem Ziel objectref aus, das mit dem Schreibzugriff 701 assoziiert ist. In dieser Ausgestaltung ermittelt der teilweise verschobene Objekt-Trap-Handler 750, oder führt bei Bedarf, Memory Storage für die Copy-To-Zielinformationen wie z. B. die, die sonst im To-Feld 412 gespeichert werden. Darüber hinaus kann die Speicherbereinigungssoftware bei Bedarf einen Speicherkapazität für Howfar-Informationen wie die führen, die sonst im Howfar-Feld 413 gespeichert werden. Wenn der Mutatorprozess 610 auf die FromSpace 420 Instanz des großen Objektes speichert, dann werden Speicherdaten entweder zur Copy-from-Instanz 450 und zur Copy-to-Instanz 450A rundgesendet oder, in Ausgestaltungen, die Speicherkapazität für Howfar-Informationen bereitstellen, der Howfar-Speicher wird inspiziert und die Speicherdaten werden zu beiden Instanzen rundgesendet. wenn das Stored-to-Feld des großen Objektes bereits kopiert wurde, und ansonsten zur Copy-from-Instanz 450 geleitet. Die Fachperson wird eine Reihe verschiedener Methoden erkennen, mit denen der Speicherbereinigungsprozess 620 das To- Feld und das Howfar-Feld aktualisieren und Variablen 751 speichern kann, die für den teilweise verschobenen Objekt-Trap-Handler 750 zur Verfügung stehen. Das Update 701 erfolgt mit einer beliebigen solchen geeigneten Methode.
  • Wie oben beschrieben, aktualisiert der Speicherbereinigungsprozess 620 das From-Feld 411 des teilweise verschobenen Objektkennungsspeichers 410, um die Copy-from-Instanz 450 des großen Objektes zu identifizieren. In dieser Ausgestaltung stehen dem Mutatorprozess 610 Zeiger auf die Copy-to-Instanz erst dann zur Verfügung, wenn der Handle für das große Objekt nach Abschluss des Kopierens aktualisiert wurde. Daher braucht keine Barriere für Zugriffe auf die Copy-to-Instanz 450A geführt zu werden. Diese Ausgestaltung ist nicht für überlappte Copy-from- und Copy-to-Instanzen konfiguriert; Support für überlappte Instanzen ist jedoch für viele verschobene Bereinigermethoden nicht notwendig, wie z. B. für generationale Säuberungs- oder Kopierbereinigungsmethoden.
  • In einer Ausgestaltung wird eine Hardware-Schreibbarriere 740 durch die Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die zum Beurteilen eines speicherungsorientierten Bytecodes verantwortlich ist (z. B. putfield_quick, putfield, aastore, usw.). In einer solchen Ausgestaltung fängt Logik, die die Hardware-Schreibbarriere 740 implementiert, Schreibvorgänge auf die Copy-from-Instanz, die durch Inhalt des From-Feldes 411 identifiziert wird. So wird beispielsweise das gewünschte Verhalten der Hardware-Schreibbarriere 640A durch die folgenden Logikgleichungen beschrieben:
    if (objectref == FROM) then
    generate gc_notify
    wobei gc_notify ein beispielhafter Trap-Handler ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen einschließlich solcher erkennen, die andere Schreibbarrierenfunktionen wie z. B. intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Howfar-Informationen können bei Bedarf als Howfar-Feld 413 in Registern 144 bereitgestellt werden (siehe 4, in 7 nicht zu sehen), um ein Trapping durch die Hardware-Schreibbarriere 740 besser nur auf diejenigen Situationen maßzuschneidern, in denen eine Rundsendung notwendig ist, um dadurch Overheads in Verbindung mit Aufrufen des teilweise verschobenen Objekt-Trap-Handlers 750 zu reduzieren.
  • 8 veranschaulicht eine Ausgestaltung mit einem Copy-to-Registerfeld (z. B. dem To-Feld 412) zusätzlich zu einem Copy-from-Registerfeld (z. B. From-Feld 411) mit assoziierter Schreibbarriere 840. Die Ausgestaltung von 8 stellt eine Schreibbarriere für Speicherungen auf Felder eines Objekts bereit, das durch den Inhalt des From-Feldes 411 identifiziert wird, und eliminiert vorteilhafterweise den teilweise verschobenen Objekt-Trap-Handler 750 und seine assoziierten Overheads. Diese Ausgestaltung erleichtert inkrementales (begrenzte Pausezeit) Kopieren von großen Objekten, ist aber wie die von 7 nicht gut für ein Begrenzte-Pausezeit-Update von großen Zahlen von Zeigern auf die ToSpace 430 Instanz eines kopierten Objektes geeignet. Wie zuvor, können gehandhabte Objektreferenzen diese Begrenzung mildern und eine allgemeine Begrenzte-Pausezeit-Verschiebung sogar von populären großen Objekten zulassen, wenn auch auf Kosten eines zusätzlichen Indirektionsniveaus.
  • Durch Führen eines Copy-to-Registerfeldes in Hardware, z. B. als To-Feld 412 in Registern 144, können Schreibzugriffe auf die Copy-from-Instanz sowohl zur Copy-from- als auch zur Copy-to-Instanz durch die Hardware-Schreibbarriere 840 ohne Software-Trap-Handler-Eingriff rundgesendet werden. In einer Ausgestaltung wird die Hardware-Schreibbarriere 840 durch Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die für die Beurteilung eines speicherungsorientierten Bytecodes verantwortlich ist. In einer solchen Ausgestaltung sendet die die Hardware-Schreibbarriere 840 implementierende Logik store_data sowohl zur Copy-from- als auch zur Copy-to-Instanz rund, die jeweils durch objectref und Inhalt des To-Feldes 412 identifiziert werden. Eine beispielhafte Hardware-Schreibbarriere 840 wird durch die folgenden Logikgleichungen beschrieben:
    Figure 00220001
    wobei offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungsorientierten Bytecode assoziiert ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen wie z. B. solche erkennen, die andere Schreibbarrierenfunktionen wie z. B. intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Da das To-Feld 412 für die Hardware-Schreibbarriere 840 zur Verfügung steht, erfolgt das Rundsenden in Hardware, und Software-Trap-Overhead wird eliminiert.
  • 9 veranschaulicht eine Ausgestaltung mit Copy-to- und Howfar-Registerfeldern (z. B. To-Feld 412 und Howfar-Feld 413) zusätzlich zum Copy-from-Registerfeld (z. B. From-Feld 411) mit assoziierter Hardware-Schreibbarriere 940. Die Ausgestaltung von 9 sieht eine Schreibbarriere für Speicherungen auf Felder eines Objektes vor, das durch den Inhalt des From-Feldes 411 identifiziert wird, und lässt es vorteilhafterweise zu, dass die Hardware-Schreibbarriere 940 auf das Rundsenden von Speicherungen auf einen noch nicht kopierten Teil des großen Objektes verzichtet, während der teilweise verschobene Objekt-Trap-Handler 650 und seine assoziierten Overheads entfallen. Wie die obigen Ausgestaltungen, so erleichtert diese Ausgestaltung ein inkrementales Kopieren von großen Objekten, ist aber nicht gut für ein Begrenzte-Pausezeit-Update von großen Zahlen von Zeigern auf die ToSpace 430 Instanz eines kopierten Objektes geeignet. Wie zuvor, können gehandlete Objektreferenzen diese Begrenzung mildern, so dass allgemeine Begrenzte-Pausezeit-Verschiebungen sogar von populären großen Objekten möglich sind, wenn auch auf Kosten eines zusätzlichen Indirektionsniveaus.
  • Durch Führen eines Copy-to-Registerfeldes in Hardware, z. B. als To-Feld 412 in Registern 144, können Schreibzugriffe auf die Copy-from-Instanz von der Hardware-Schreibbarriere 940 sowohl zur Copy-from- als auch zur Copy-to-Instanz rundgesendet werden. Indem ferner ein Howfar-Registerfeld in Hardware geführt wird, z. B. als Howfar-Feld 413 in Registern 144, kann das Rundsenden auf diejenigen Schreibzugriffe begrenzt werden, für die das jeweilige Zielfeld des Schreibzugriffs bereits auf ToSpace 430 kopiert wurde. In jedem Fall erfolgt das Handling des Schreibzugriffs auf das teilweise verschobene Objekt ohne Software-Trap-Handler-Eingriff. In einer Ausgestaltung wird die Hardware-Schreibbarriere 940 durch Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die für das Beurteilen eines speicherungsorientierten Bytecodes verantwortlich ist. In einer solchen Ausgestaltung sendet die Hardware-Schreibbarriere 940 implementierende Logik store_data sowohl zur Copy-from- als auch zur Copy-to-Instanz rund, wenn das Zielobjektfeld in einem bereits kopierten Teil des großen Objektes ist, und leitet store_data zur Copy-from-Instanz, wenn das Zielobjektfeld in einem noch nicht kopierten Teil des großen Objektes ist. Eine beispielhafte Hardware-Schreibbarriere 940 wird durch die folgenden Logikgleichungen beschrieben:
    Figure 00230001
    wobei offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungsorientierten Bytecode assoziiert ist. In einigen Ausgestaltungen kann das Leiten von store_data zur Copy-from-Instanz einfach dadurch erzielt werden, dass zugelassen wird, dass der Schreibzugriff normal ohne Intervention der Hardware-Schreibbarriere 940 vollendet wird. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen wie z. B. solche erkennen, die andere Schreibbarrierenfunktionen wie intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Da das Howfar-Feld 413 für die Hardware-Schreibbarriere 940 zur Verfügung steht, kann die Hardware-Schreibbarriere 940 selektiv auf das Schreiben von store_data auf die Copy-to-Instanz verzichten. Diese geringfügige Optimierung kann die Leistung verbessern, da nur ein einziger Schreibvorgang durchgeführt wird, anstatt zwei Schreibvorgänge rundzusenden.
  • Schreibbarriere in Verbindung mit Copy-from- und Copy-to-Instanzkennungsspeichern
  • Zusätzliche Ausgestaltungen werden nunmehr mit Bezug auf die 10 und 11 beschrieben. Wie einige der zuvor beschriebenen Ausgestaltungen, nutzen diese zusätzlichen Ausgestaltungen Hardware-Support (z. B. eine Hardware-Schreibbarriere und den teilweise verschobenen Objekt-Kennungsspeicher 410), um Schreibvorgänge auf die FromSpace 420 Instanz eines teilweise verschobenen großen Objektes ohne Software-Trap-Handler-Eingriff angemessen zu handhaben. Darüber hinaus haben diese zusätzlichen Ausgestaltungen jedoch eine Barriere für Schreibvorgänge auf die ToSpace 430 Instanz eines teilweise verschobenen großen Objekts. Auf diese Weise unterstützen diese zusätzlichen Ausgestaltungen sowohl inkrementales Kopieren eines großen Objektes als auch ein inkrementales Update von Zeigern auf ein populäres Objekt für insgesamt Begrenzte-Pausezeit-Verschiebung von großen und/oder populären Objekten ohne gehandlete Objektreferenzen.
  • In den Ausgestaltungen der 10 und 11 aktualisiert der Speicherbereinigungsprozess 620 inkremental Zeiger (d. h. objectrefs) auf das große Objekt. Schreibzugriffe des Mutatorprozesses 610 auf die FromSpace 420 Instanz oder die ToSpace 430 Instanz werden von einer Hardware-Schreibbarriere, z. B. der Hardware-Schreibbarriere 1040 oder der Hardware-Schreibbarriere 1140, rundgesendet (oder auf geeignete Weise geleitet), so dass die beiden Instanzen „synchron" gehalten werden, während die objectrefs aktualisiert werden. Da die beiden Instanzen synchron gehalten werden, ist die Memory-Referenzierungsstruktur für Referenzierungszustände robust, in denen sich einige objectrefs auf eine FromSpace 420 Instanz und andere auf die entsprechende ToSpace 430 Instanz beziehen. Das Begrenzte-Pausezeit-Update von objectrefs, die sich auf das große Objekt beziehen, erfolgt durch inkrementales Aktualisieren solcher objectrefs, so dass sie sich auf die ToSpace 430 Instanz (anstatt auf die FromSpace 420 Instanz) beziehen. Man beachte, dass in den Ausgestaltungen der 10 und 11 die FromSpace 420 Instanz und die ToSpace 430 Instanz einander nicht überlappen dürfen.
  • Mit Bezug auf 10, die Hardware-Schreibbarriere 1040 bietet eine Barriere für Schreibzugriffe auf die Copy-from-Instanz 450 oder die Copy-to-Instanz 450A. Die Hardware-Schreibbarriere 1040 unterstützt inkrementales Begrenzte-Pausezeit-Kopieren, wie oben mit Bezug auf die Hardware-Schreibbarriere 840 beschrieben wurde. Die Hardware-Schreibbarriere 1040 spricht jedoch auch auf das Copy-to-Registerfeld (z. B. auf das To-Feld 412) an. Schreibzugriffe auf die Copy-from-Instanz 450 oder die Copy-to-Instanz 450A werden sowohl zur Copy-from-Instanz 450 als auch zur Copy-to-Instanz 450A rundgesendet, so dass die Datenzustände der beiden Instanzen synchronisiert werden. Auf diese Weise können objectrefs auf das teilweise verschobene große Objekt inkremental aktualisiert werden, da ein Lesezugriff auf eine der beiden Instanzen sich auf denselben Feldzustand auflöst.
  • In einer Ausgestaltung wird die Hardware-Schreibbarriere 1040 durch Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die zum Beurteilen eines speicherungsorientierten Bytecodes verantwortlich ist. In einer solchen Ausgestaltung sendet die die Hardware-Schreibbarriere 1040 implementierende Logik store_data jeweils zur Copy-from- und zur Copy-to-Instanz rund, die jeweils durch den Inhalt des From-Feldes 411 und des To-Feldes 412 identifiziert werden. Eine beispielhafte Hardware-Schreibbarriere 1040 wird durch die nachfolgenden Logikgleichungen beschrieben:
    Figure 00250001
    wobei offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungsorientierten Bytecode assoziiert ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen wie z. B. solche erkennen, die andere Schreibbarrierenfunktionen wie intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Da das From-Feld 411 und das To-Feld 412 für die Hardware-Schreibbarriere 1040 zur Verfügung stehen. können Speicherungen auf die Copy-from-Instanz 450 oder die Copy-to-Instanz 450A, die jeweils dadurch identifiziert werden, erkannt werden, und die Rundsendung zu beiden Instanzen kann in Hardware ohne Software-Trap-Overhead erfolgen.
  • 11 zeigt eine Ausgestaltung, in der ein How-Far-Registerfeld (z. B. Howfar- Feld 413) und eine Modusanzeige (z. B. das Mode-Feld 1114 der Register 114) hinzukommen. Wie in der Ausgestaltung von 10, bildet die Hardware-Schreibbarriere 1140 eine Barriere für Schreibzugriffe auf die Copy-from-Instanz 450 oder die Copy-to-Instanz 450A. Die Hardware-Schreibbarriere 1140 unterstützt inkrementales Begrenzte-Pausezeit-Kopieren, indem sie gewährleistet, dass kopierte Teile der FromSpace 420 und der ToSpace 430 Instanz synchron gehalten werden. Die Hardware-Schreibbarriere 1140 lässt es vorteilhafterweise zu, dass der Hardware-Prozessor 100 auf ein Rundsenden von Speicherdaten zu einem noch nicht kopierten Teil des großen Objektes während einer Kopierphase verzichtet, die in der Ausgestaltung von 11 durch einen COPY Zustand des Mode-Feldes 1114 angedeutet wird. Während einer Zeiger-Update-Phase, die durch einen PTR_UPDATE-Zustand des Mode-Feldes 1114 angedeutet wird, werden jedoch Schreibzugriffe auf die Copy-from-Instanz 450 oder die Copy-to-Instanz 450A sowohl zur Copy-from-Instanz 450 als auch zur Copy-to-Instanz 450A rundgesendet. Der Speicherbereinigungsprozess 620 aktualisiert das Mode-Feld 1114, so dass es einer aktuellen Phase einer Verschiebung eines großen Objekts entspricht.
  • In einer Ausgestaltung wird die Hardware-Schreibbarriere 1140 durch die Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die zum Beurteilen eines speicherungsorientierten Bytecodes verantwortlich ist. In einer solchen Ausgestaltung sendet die Hardware-Schreibbarriere 1140 implementierende Logik store_data sowohl zur Copy-from- als auch zur Copy-to-Instanz rund, wenn das Zielobjektfeld in einem bereits kopierten Teil des großen Objektes ist oder wenn das große Objekt bereits vollständig kopiert wurde und die Verschiebung in eine Zeiger-Update-Phase eingetreten ist. Während der Kopierphase leitet die Hardware-Schreibbarriere 1140 implementierende Logik store_data zur Copy-from-Instanz, wenn das Zielobjektfeld in einem noch nicht kopierten Teil des großen Objektes ist. Eine beispielhafte Hardware-Schreibbarriere 1140 wird durch die folgenden Logikgleichungen beschrieben:
    Figure 00260001
    wobei der Zustand des Mode-Feldes 1114, MODE, eine Verschiebungsphase anzeigt (z. B. COPY oder PTR_UPDATE), und offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungsorientierten Bytecode assoziiert ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen wie z. B. solche erkennen, die andere Schreibbarrierenfunktionen wie intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Da das Howfar-Feld 413 und das Mode-Feld 1114 für die Hardware-Schreibbarriere 1140 zur Verfügung stehen, kann die Hardware-Schreibbarriere 1140 selektiv auf das Schreiben von store_data auf die Copy-to-Instanz während der Kopierphase einer großen Objektverschiebung verzichten, während Schreibvorgänge in der Zeiger-Update-Phase rundgesendet werden. Diese geringfügige Optimierung kann die Leistung verbessern, indem nur ein einziger Schreibvorgang durchgeführt wird, anstatt zwei Schreibvorgänge in der Kopierphase rundzusenden. Darüber hinaus kann der Verschiebungsmodus dadurch angezeigt werden, dass zugelassen wird, dass der Speicherbereinigungsprozess 620 die Vollendung der Kopierphase in einem Zustand des Howfar-Feldes 413 codiert. Die Fachperson wird erkennen, dass in den obigen Logikgleichungen ein Wert im Howfar-Feld 413 von gleich oder kleiner als null (0) verwendet werden kann, um die Vollendung der Kopierphase zu codieren, wodurch das Mode-Feld 1114 überflüssig wird.
  • Lese- und Schreibbarrieren in Verbindung mit dem Copy-from-Instanzkennungspeicher
  • Es werden nun zusätzliche Ausgestaltungen mit Bezug auf die 12–14 beschrieben. Wie einige der zuvor beschriebenen Ausgestaltungen, so nutzen diese zusätzlichen Ausgestaltungen Hardware-Support (z. B. eine Hardware-Schreibbarriere und den teilweise verschobenen Objektkennungsspeicher 410), um Schreibvorgänge auf die FromSpace 420 Instanz eines teilweise verschobenen großen Objektes angemessen zu handhaben. Diese zusätzlichen Ausgestaltungen haben jedoch auch eine Barriere für Lesevorgänge von einer FromSpace 420 Instanz eines teilweise verschobenen großen Objekts. Auf diese Weise unterstützen diese zusätzlichen Ausgestaltungen Begrenzte-Pausezeit-Kopieren sowie Begrenzte-Pausezeit-Updates von Zeigern auf das große Objekt ohne gehandlete Objektreferenzen.
  • In den Ausgestaltungen der 12–14 kopiert der Speicherbereinigungsprozess 620 inkremental das große Objekt von einer FromSpace 420 Instanz auf eine ToSpace 430 Instanz während einer Kopierphase (MODE = COPY) und aktualisiert inkremental Zeiger (d. h. objectrefs) auf das große Objekt während einer Zeiger-Update-Phase (MODE = PTR_UPDATE). Während der Kopierphase der Verschiebung des großen Objekts werden Schreibzugriffe des Mutatorprozesses 610 auf die FromSpace 420 Instanz rundgesendet oder auf geeignete Weise von einem teilweise verschobenen Objekt-Trap-Handler z. B. dem teilweise verschobenen Objekt-Trap-Handler 120 (12) oder durch eine Hardware- Schreibbarriere wie z. B. die Hardware-Schreibbarriere 1340 (13) oder die Hardware-Schreibbarriere 1440 (14) geleitet. Während der Zeiger-Update-Phase der Verschiebung eines großen Objekts werden Schreib- und Lesezugriffe des Mutatorprozesses 610 auf die FromSpace 420 Instanz zur ToSpace 430 Instanz umgeleitet.
  • 12 veranschaulicht eine Ausgestaltung mit einem Copy-from-Registerfeld mit assoziierten Lese- und Schreibbarrieren. Insbesondere beinhaltet die Ausgestaltung von 12 das From-Feld 411, die Hardware-Lesebarriere 1242, die Hardware-Schreibbarriere 1241 und den teilweise verschobenen Objekt-Trap-Handler 1250. Die Hardware-Lesebarriere 1242 und die Hardware-Schreibbarriere 1241 sind illustrativ als Lese- und Schreibbarrieren-Hardware 1240 dargestellt. Je nach der Implementation können die Hardware-Schreibbarriere 1241 und die Hardware-Lesebarriere 1242 jedoch auch Hardware gemeinsam nutzen oder können auf separater Hardware basieren. In einer Ausgestaltung beinhaltet Logik der Ganzzahleneinheit 142 (1), die zum Beurteilen von speicherungsorientierten Bytecodes verantwortlich ist, die Hardware-Schreibbarriere 1241, und Logik der Ganzzahleneinheit 142, die zum Beurteilen von ladungsorientierten Bytecodes verantwortlich ist (z. B. getfield_quick, getfield, aaload, usw.), hat die Hardware-Lesebarriere 1242.
  • Der Mutatorprozess 610 führt Lese- und Schreibzugriffe von und zu dem bereinigten Raum 630 durch. Ein bestimmter Lese- oder Schreibzugriff wird von der Lese- und Schreibbarrieren-Hardware 1240 selektiv abgefangen, wenn der Lese- oder Schreibzugriff die FromSpace 420 Instanz eines teilweise verschobenen Objekts anpeilt. Lese- und Schreibbarrieren-Hardware 1240 triggert den teilweise verschobenen Objekt-Trap-Handler 1250 als Reaktion auf eine Übereinstimmung zwischen dem Inhalt des From-Feldes 411 und dem Ziel objectref, das mit dem Schreibzugriff 701 oder dem Lesezugriff 1202 assoziiert ist. In einer Ausgestaltung spricht die Lese- und Schreibbarrieren-Hardware 1240 auf ein Mode-Feld 1114 der Register 144 an, wodurch das Verhalten der Hardware-Lesebarriere 1242 auf der Basis des Zustands des Mode-Feldes 1114 geändert wird. In einer solchen Ausgestaltung fängt die Hardware-Lesebarriere 1242 selektiv nur während der Zeiger-Update-Phase der Verschiebung eines großen Objekts ab.
  • Eine beispielhafte Hardware-Schreibbarriere 1241 wird durch die folgenden Logikgleichungen beschrieben:
    if (objectref == FROM) then
    generate gc_notify
    wobei gc_notify ein Trap-Handler wie z. B. der teilweise verschobene Objekt-Trap-Handler 1250 ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen wie z. B. solche erkennen, die andere Schreibbarrierenfunktionen wie intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Eine beispielhafte Hardware-Lesebarriere 1242 wird durch die folgenden Logikgleichungen beschrieben:
    if ((MODE == PTR_UPDATE) && (objectref == FROM)) then
    generate gc_notify
  • Alternative Ausgestaltungen können selektiv während der Kopier- und Zeiger-Update-Phasen der Verschiebung eines großen Objekts mit entsprechendem Handling durch den teilweise verschobenen Objekt-Trap-Handler 1250 abfangen, obwohl dies auf Kosten eines größeren Trap-Handler-Overheads geht.
  • Während der Kopierphase ermittelt der teilweise verschobene Objekt-Trap-Handler 1250 oder führt bei Bedarf Memory Storage für Copy-to-Zielinformationen wie die, die sonst im To-Feld 412 gespeichert werden. Darüber hinaus kann der teilweise verschobene Objekt-Trap-Handler 1250 bei Bedarf einen Speicher für Howfar-Informationen wie die führen, die sonst im Howfar-Feld 413 gespeichert werden. Wenn der Mutatorprozess 610 auf die FromSpace 420 Instanz des großen Objektes speichert, dann werden Speicherdaten entweder sowohl zur Copy-from-Instanz 450 als auch zur Copy-to-Instanz 450A rundgesendet oder, in Ausgestaltungen, die Speicher für Howfar-Informationen bereitstellen, der Howfar-Storage wird inspiziert und die Speicherdaten werden zu beiden Instanzen rundgesendet, wenn das Stored-to-Feld des großen Objektes bereits kopiert wurde, und ansonsten zur Copy-from-Instanz 450 geleitet.
  • Während der Zeiger-Update-Phase leitet der teilweise verschobene Objekt-Trap-Handler 1250 Lese- und Schreibzugriffe, die eine FromSpace 420 Instanz eines teilweise verschobenen großen Objektes zur ToSpace 430 Instanz davon anpeilen. Wie zuvor, ermittelt der teilweise verschobene Objekt-Trap-Handler 1250, oder führt bei Bedarf Memory Storage für die Copy-to-Zielinformationen wie z. B. die, die sonst im To-Feld 412 gespeichert werden. In jedem Fall leitet der teilweise verschobene Objekt-Trap-Handler 1250 sowohl Lese- als auch Schreibzugriffe zur ToSpace 430 Instanz um. Auf diese Weise geht ein Lesezugriff auf das teilweise verschobene Objekt auf die ToSpace 430 Instanz, die garantiert auf dem neuesten Stand ist.
  • Beispielhafte Schreib-Trap- und Lese-Trap-Funktionen für den teilweise verschobenen Objekt-Trap-Handler 1250 lauten wie folgt:
    Figure 00290001
    Figure 00300001
    wobei read_destination der Zielort für einen ladungsorientierten Bytecode ist.
  • Im Allgemeinen wird Overhead aufgrund von Trapping für den Lesebarrierenfall wahrscheinlich größer sein als das in dem Fall, in dem nur eine Schreibbarriere vorhanden ist, weil Lesezugriffe typischerweise üblicher sind als Schreibzugriffe in einem bestimmten Anweisungsstrom und in jedem Fall zusätzlich zu Schreibzugriffen erfolgen. Teilweise aus diesem Grund ist die Hardware-Lesebarriere 1242 für Lesevorgänge in der Zeiger-Update-Phase von der FromSpace 420 Instanz des teilweise verschobenen großen Objekts selektiv. Die Hardware-Lesebarriere 1242 kann jedoch bei Bedarf Lesevorgänge von der FromSpace 420 Instanz des teilweise verschobenen großen Objekts unabhängig von der Verschiebungsphase abfangen. In einer solchen Ausgestaltung kann der teilweise verschobene Objekt-Trap-Handler 1250 so konfiguriert sein, dass er eine überlappende Copy-from-Instanz 450 und Copy-to-Instanz 450A intelligent handlet. 15 illustriert eine Überlappung der From-Instanz 1560 und der To-Instanz 1570, wobei ein kopierter Teil 1561 auf den Teil 1571 der To-Instanz 1570 kopiert wurde. Das From-Feld 411, das To-Feld 412 und das Howfar-Feld 413 codieren den teilweise verschobenen Objektzustand wie oben beschrieben. In der Ausgestaltung von 15 kopiert der Speicherbereinigungsprozess 620 das große Objekt von hinten nach vorne (oder von vorne nach hinten), je nach der relativen Überlappung der From-Instanz 1560 und der To-Instanz 1570. Um überlappte From- und To-Instanzen zu erleichtern, sendet der teilweise verschobene Objekt-Trap-Handler 1550 Schreibvorgänge nicht rund und leitet stattdessen einen auf den nicht kopierten Teil 1560 gerichteten Schreibvorgang zur From-Instanz 1560 und leitet einen auf den kopierten Teil 1561 gerichteten Schreibvorgang zur To-Instanz 1570. Eine geeignete Modifikation zur Schreib-Trap-Funktion des teilweise verschobenen Objekt-Trap-Handlers 1250 lautet wie folgt:
    Figure 00310001
    wobei COPY_DIRECTION anhand der relativen Positionen der From-Instanz 1560 und der To-Instanz 1570 ermittelbar sind, die jeweils durch das From-Feld 411 und das To-Feld 412 codiert sind. Modifikationen zur Lese-Trap-Funktion des teilweise verschobenen Objekt-Trap-Handlers 1250, um die ladungsorientierten Zugriffe entsprechend umzuleiten, sind analog.
  • 13 veranschaulicht eine Ausgestaltung mit einem Copy-to-Registerfeld (z. B. das To-Feld 412) zusätzlich zu einem Copy-from-Registerfeld (z. B. das From-Feld 411) mit assoziierter Lese- und Schreibbarrieren-Hardware 1340. Wie zuvor, beinhaltet diese Ausgestaltung eine Modusanzeige (z. B. Mode-Feld 1114 der Register 144), die vom Speicherbereinigungsprozess 620 geführt wird, damit Lese- und Schreibbarrieren-Hardware 1340 zwischen einer Kopierphase und einer Zeiger-Update-Phase einer Verschiebung eines großen Objekts unterscheiden können. Im Vergleich zur Ausgestaltung von 12 bietet die von 13 sowohl Lesebarrieren- als auch Schreibbarrierensupport in Hardware (z. B. als Hardware-Lesebarriere 1342 für Speicherungen auf Felder eines Objektes, das durch den Inhalt des From-Feldes 411 identifiziert wird, und eine Hardware-Schreibbarriere 1341 für Speicherungen auf Felder eines Objektes, das durch den Inhalt des From-Feldes 411 identifiziert wird), wodurch vorteilhafterweise teilweise verschobener Objekt-Trap-Handler 1250 und seine assoziierten Overheads eliminiert werden.
  • Durch Führen eines Copy-to-Registerfeldes in Hardware, z. B. als To-Feld 412 in Registern 144, können Schreibzugriffe auf die Copy-from-Instanz während einer Kopierphase (MODE = COPY) sowohl auf die Copy-from- als auch die Copy-to-Instanz durch die Hardware-Schreibbarriere 1341 ohne Software-Trap-Handler-Eingriff rundgesendet werden. Während einer Zeiger-Update-Phase (MODE = PTR_UPDATE) werden Schreibzugriffe auf die Copy-from-Instanz durch die Hardware-Schreibbarriere 1341 zur Copy-to-Instanz umgeleitet, wiederum ohne Software-Trap-Handler-Eingriff. Lesezugriffe von der Copy-from-Instanz werden ebenfalls während der Zeiger-Update-Phase durch die Hardware-Lesebarriere 1342 ohne Software-Trap-Handler-Eingriff zur Copy-to-Instanz umgeleitet. Kopierphasen-Lesezugriffe auf die Copy-from-Instanz werden normal abgeschlossen.
  • In einer Ausgestaltung wird Lese- und Schreibbarrieren-Hardware 1340 durch Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die für die Beurteilung von Bytecodes verantwortlich ist. Die Hardware-Schreibbarriere 1341 wird durch Logik der Ganzzahleneinheit 142 bereitgestellt, die für die Beurteilung von speicherungsorientierten Bytecodes verantwortlich ist, und Hardware-Lesebarriere 1342 wird von Logik der Ganzzahleneinheit 142 bereitgestellt, die für die Beurteilung von ladungsorientierten Bytecodes verantwortlich ist.
  • Während der Kopierphase sendet die Hardware-Schreibbarriere 1342 implementierende Logik store_data zu Copy-from- und Copy-to-Instanzen rund, die jeweils durch objectref und den Inhalt des To-Feldes 412 identifiziert werden, während in der Zeiger-Update-Phase die Hardware-Schreibbarriere 1342 implementierende Logik store_data nur auf die Copy-to-Instanz umleitet. Eine beispielhafte Hardware-Schreibbarriere 1342 wird durch die folgenden Logikgleichungen beschrieben:
  • Figure 00320001
  • Ebenso wird eine beispielhafte Hardware-Lesebarriere 1341 durch die folgenden Logikgleichungen beschrieben.
    Figure 00320002
    Figure 00330001
    wobei in jedem Fall offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungs- oder ladungsorientierten Bytecode assoziiert ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen einschließlich solcher erkennen, die die Hardware-Schreibbarriere 1341 und die Hardware-Schreibbarriere 1342 kombinieren, sowie Implementationen, die die Hardware-Schreibbarriere 1342 mit anderen Schreibbarrierenfunktionen wie intergenerationales Zeigerspeicher-Trapping wie oben beschrieben kombinieren. Da das To-Feld 412 für die Hardware-Schreibbarriere 1342 und die Hardware-Lesebarriere 1341 zur Verfügung steht, können Rundsendung und Umleitung in Hardware ausgeführt werden und Software-Trap-Overhead wird eliminiert.
  • 14 veranschaulicht eine Ausgestaltung, die ein Howfar-Registerfeld (z. B. das Howfar-Feld 413) hinzufügt. Wie in der Ausgestaltung von 13, stellt die Lese- und Schreibbarrieren-Hardware 1440 Barrieren für Lese- und Schreibzugriffe von und zur Copy-from-Instanz 450 bereit. Darüber hinaus lenkt die Lese- und Schreibbarrieren-Hardware 1440 Lese- und Schreibzugriffe zu einer geeigneten FromSpace 420 oder ToSpace 430 Instanz, je nach dem, ob das von einem speicherungs- oder ladungsorientierten Bytecode referenzierte Feld bereits auf die ToSpace 430 Instanz kopiert wurde. Bei einem Betrieb in Verbindung mit dem Howfar-Feld 413 lässt es die Hardware-Schreibbarriere 1441 vorteilhafterweise zu, dass der Hardware-Prozessor 100 ohne Rundsenden von Speicherdaten zu einem noch nicht kopierten Teil des großen Objektes während einer Kopierphase auskommt, angezeigt durch einen COPY-Zustand des Mode-Feldes 1114. In der Zeiger-Update-Phase wird garantiert, dass die ToSpace 430 Instanz auf dem neuesten Stand ist; somit lässt es die Hardware-Lesebarriere 1442 durch Umleiten von Lesezugriffen darauf zu, dass der Hardware-Prozessor 100 vorteilhafterweise ohne Rundsenden von Speicherdaten in der Zeiger-Update-Phase auskommt. Da die Rundsendung von Speicherdaten ausfällt, ist die Ausgestaltung von 14 besonders für die Unterstützung von überlappenden FromSpace 420 und ToSpace 430 Instanzen geeignet.
  • In einer Ausgestaltung wird die Lese- und Schreibbarrieren-Hardware 1440 durch Logik der Ganzzahleneinheit 142 (1) bereitgestellt, die für die Beurteilung von Bytecodes verantwortlich ist. Die Hardware-Schreibbarriere 1441 wird durch Logik der Ganzzahleneinheit 142 bereitgestellt, die für die Beurteilung von speicherungsorientierten Bytecodes verantwortlich ist, und die Hardware-Lesebarriere 1442 wird durch Logik der Ganzzahleneinheit 142 bereitgestellt, die für die Beurteilung von ladungsorientierten Bytecodes verantwortlich ist. Eine beispielhafte Hardware-Schreibbarriere 1442 wird durch die folgenden Logikgleichungen beschrieben:
  • Figure 00340001
  • Ebenso wird eine beispielhafte Hardware-Lesebarriere 1341 durch die folgenden Logikgleichungen beschrieben:
    Figure 00340002
    wobei read_destination das Ziel für einen ladungsorientierten Bytecode ist, und wobei in jedem Fall offset der Relativzeiger in das große Objekt des Zielfeldes ist, das mit dem speicherungs- oder ladungsorientierten Bytecode assoziiert ist. Die Fachperson wird eine Reihe verschiedener geeigneter Logikimplementationen einschließlich Logikimplementationen erkennen, die die Hardware-Lesebarriere 1441 und die Hardware-Schreibbarriere 1442 kombinieren, sowie Implementationen, die die Hardware-Schreibbarriere 1442 mit anderen Schreibbarrierenfunktionen wie intergenerationalem Zeigerspeicher-Trapping wie oben beschrieben kombinieren.
  • Lese- und Schreibbarrieren, die mit Copy-to-Instanzkennungspeicher assoziiert sind
  • Eine Serie von Variationen über die Ausgestaltungen der 12-14 beinhalten Lese- und Schreibbarrieren, die mit einem Copy-to-Instanzkennungsspeicher anstatt mit einem Copy-from-Instanzkennungsspeicher assoziiert sind. Wie zuvor, Eigen diese Variationen aufeinander folgende Levels von zusätzlichem Hardware-Support hinzu, z. B. From-Feld 411 und Howfar-Feld 413 Support, um Software-Trap-Handler-Overhead zu eliminieren und eine Überlappung von Copy-from- und Copy-to-Instanzen 450 und 450A zuzulassen. Die Variationen unterstützen sowohl Begrenzte-Pausezeit-Kopieren als auch Begrenze-Pausezeit-Updates von Zeigern auf ein teilweise verschobenes großes Objekt. Diese Variationen werden nachfolgend in Analogie zu den Ausgestaltungen der 12–14 beschrieben, und die Fachperson wird geeignete Modifikationen auf der Basis dieser Beschreibung erkennen.
  • Der Speicherbereinigungsprozess 620 aktualisiert Zeiger auf das große Objekt, d. h. von seiner FromSpace 420 Instanz zu seiner ToSpace 430 Instanz, bevor die Objektdaten kopiert werden. Auf diese Weise wird die Reihenfolge der Zeiger-Update- und Kopierphasen umgekehrt. Lese- und Schreibbarrieren leiten Lese- und Schreibzugriffe um, die auf Copy-to-Instanz 450A anstatt Copy-from-Instanz 450 gerichtet sind. In einer Ausgestaltung fangen Hardware-Lese- und Schreibbarrieren Zugriffe auf die Copy-to-Instanz 450A ab, so dass eine teilweise verschobene Objekt-Trap-Handler-Software aufgerufen wird, die das eigentliche Weiterleiten zur Copy-from-Instanz durchführt. Der teilweise verschobene Objekt-Trap-Handler kann bei Bedarf Speicher für Howfar-Informationen wie die führen, die sonst im Howfar-Feld 413 gespeichert werden. Wenn der Mutatorprozess 610 auf die ToSpace 420 Instanz des großen Objektes speichert, dann werden Speicherdaten zur Copy-to-Instanz 450A geleitet, wenn das Stored-to-Feld des großen Objektes bereits kopiert wurde, ansonsten werden sie zur Copy-from-Instanz 450 geleitet. Ebenso wird, wenn der Mutatorprozess 610 von der ToSpace 420 Instanz des großen Objekts lädt, das Laden von der Copy-to-Instanz 450A durchgeführt, wenn das Stored-to-Feld des großen Objekts bereits kopiert wurde, ansonsten wird es von der Copy-from-Instanz 450 durchgeführt. Support für überlappte FromSpace 430 und ToSpace 430 Instanzen wird wie oben mit Bezug auf die Ausgestaltungen der 12 und 14 beschrieben bereitgestellt. Alternativ kann die Lesebarriere, wenn kein Support für überlappende Regionen benötigt wird, Ladungen zur Copy-from-Instanz leiten, und die Schreibbarriere kann Speicherdaten zur Copy-from- und zur Copy-zu-Instanz rundsenden.
  • Wie oben, kann Software-Trap-Overhead dadurch eliminiert werden, dass mehr Register und komplexeres Verhalten in die Hardware eingebaut werden. So beinhaltet beispielsweise eine Ausgestaltung das To-Feld 412 und das From-Feld 411. Eine Hardware-Schreibbarriere, die auf die Übereinstimmung zwischen einem Speicherziel und dem To-Feld 412 anspricht, sendet Speicherdaten zur Copy-to-Instanz 450A und zur Copy-from-Instanz 450 rund. Eine Hardware-Lesebarriere, die auf eine Übereinstimmung zwischen einer Ladungsquelle und dem To-Feld 412 anspricht, leitet Ladevorgänge zur Copy-from-Instanz 450 um. Eine andere Ausgestaltung beinhaltet das Howfar-Feld 413 zusätzlich zum From-Feld 411 und zum To-Feld 412. Die Hardware-Schreibbarriere und die Hardware-Lesebarriere leiten Speicherdaten und Ladedaten zu kopierten Teilen der Copy-to-Instanz 450A und zu unkopierten Teilen der Copy-from-Instanz 450. Die Fachperson wird geeignete Logik für die einzelnen Ausgestaltungen auf der Basis der obigen Beschreibung erkennen.
  • Objektreferenzierungsformate
  • 16 veranschaulicht eine Ausgestaltung einer Objektreferenz (objectref), wie im Hardware-Prozessor 100 repräsentiert ist. Drei Bits der objectref können für Speicherbereinigungshints verwendet werden. Ein zusätzliches Handle-Bit H zeigt an, ob das Objekt durch objectref direkt oder indirekt durch einen Handle referenziert wird. Handles bieten eine Referenzierungsmethode, die die Verschiebung von Memory-Objekten ohne aufwändige Updates von Zeigern (oder objectrefs) darauf erleichtert, jedoch auf Kosten eines zusätzlichen Indirektionsniveaus. Diese beiden Felder werden ausmaskiert, bevor sie zur Ganzzahleneinheit 142 (1) des Hardware-Prozessors 100 geleitet werden.
  • In einer Ausgestaltung des Hardware-Prozessors 100 und von bereinigtem Raum 630 (6–14) wird ein Objekt 1700 im Memory mit einem Header-Teil 1710 und einem Instanzvariablen-Speicherteil 1770 repräsentiert. 17A veranschaulicht eine solche Ausgestaltung. Der Header-Teil 1710 beinhaltet ein 32-Bit-Wort, das an sich einen Methoden-Vektortabellen-Basisteil 1712 zum Repräsentieren der Objektklasse und fünf Bits von zusätzlichem Speicher 1714 beinhaltet, der für den Synchronisationsstatus des Objekts und Informationen für den Speicherbereiniger reserviert sind. Bei Bedarf kann ein zweites Header-Wort, z. B. Monitor-Zeiger 1716, die Adresse eines für das Objekt zugeordneten Monitors beinhalten, so dass alle fünf Bits von zusätzlichem Speicher 1714 im ersten Header-Wort für Speicherbereinigungsinformationen zur Verfügung stehen. In der Ausgestaltung von 17A zeigt eine Objektreferenz (objectref) auf den Ort des Methoden-Vektortabellen-Basisteils 1712, um das Overhead des Methodenaufrufs zu minimieren.
  • Es stehen einem Speicherbereiniger wie dem Bereinigerprozess 620 drei Bits an Header-Teil 1710 zur Verfügung. Im Header-Teil 1710 werden drei Lower-Order-Bits (Header[2:0]) und zwei High-Order-Bits (Header[31:30]) ausmaskiert, wenn der Header als Zeiger behandelt wird. Drei dieser Bits (Header[31:30,2]) stehen dem Speicherbereiniger zum Speichern von Informationen über das Objekt 1700 zur Verfügung. Bits 1 und 0 können zum Halten von LOCK- und WANT-Bits für die Objektsynchronisation verwendet werden. Alternativ kann ein zweites Header-Wort, z. B. Monitor-Zeiger 1716, zum Führen des Synchronisationsstatus von Objekt 1700 bereitgestellt werden, so dass alle fünf Bits für Speicherbereinigungssupport verbleiben. Wie die Bits für den Speicherbereinigungssupport verwendet werden, hängt von dem/den jeweiligen Typen) von durch Speicherbereinigungsmethoden implementiertem Bereinigungsprozess 620 und ggf. dem Speicherbereinigungs-Trap-Handler ab. Mögliche Verwendungszwecke sind Mark-Bits, Zählerbits zum Altern von Objekten innerhalb einer Generation usw. Wie oben beschrieben, stehen in einer Ausgestaltung mit optionalem zweitem Header-Wort des Header-Teils 1710 fünf Bits für einen Speicherbereiniger wie dem Bereinigungsprozess 620 zur Verfügung.
  • In der Ausgestaltung von 17A beginnt der Instanzvariablen-Speicherteil 1720 mit einem Wort nach dem Methoden-Vektortabellen-Basisteil 1712 und enthält Instanzvariablen des Objektes 1700. Das niedrigstwertige Bit einer objectref gibt vor, ob die Referenz gehandlet (== 1) ist oder nicht (== 0). Ein alternatives, „gehandlet", Objektformat ist in 17B dargestellt. Eine gehandelte Referenz wird dann aufgestellt, wenn Objekt 1700b erzeugt wird, und alle nachfolgenden Referenzen durch den Handle, d. h. den Speicherzeiger 1750b, gehen, um auf das Objekt zuzugreifen. Dieser Support ist für einige Typen von Speicherbereinigern vorgesehen, was die Kosten für Zeiger-Updates bei der Objektverschiebung durch Kopieren von Handles anstatt des zu Grunde liegenden Objektspeichers reduziert, einschließlich denen für Instanzvariablen.
  • Gehandlete Objektreferenzen lassen es zu, dass Speicherbereinigungssysteme wie die, die oben mit Bezug auf die 7–9 beschrieben wurden, eine Begrenzte-Pausezeit-Leistung für Zeiger-Updates auf ein kopiertes Objekt aufweisen. In anderen Speicherbereinigungssystemen, für die ein Begrenzte-Pausezeit-Zeiger-Update von großen Zahlen von Referenzierungszeigern von der sich dadurch ergebenden Barrierenkonfiguration unterstützt wird, z. B. in den oben mit Bezug auf die 10–14 beschriebenen Ausgestaltungen, werden direkte Objektreferenzen bevorzugt.
  • Die Erfindung wurde zwar mit Bezug auf verschiedene Ausgestaltungen beschrieben, aber es ist zu verstehen, dass diese Ausgestaltungen illustrativ sind und dass der Umfang der Erfindung nicht darauf begrenzt ist. Anspruchsbegriffe wie erste Anweisung, zweite Anweisung, dritte Anweisung usw. dienen lediglich zur Identifikation und sind nicht als eine bestimmte Reihenfolge erfordernd anzusehen. Es sind zahlreiche Variationen, Modifikationen, Zusätze und Verbesserungen der beschriebenen Ausgestaltungen möglich. So wurde beispielsweise die vorliegende Erfindung zwar hierin mit Bezug auf beispielhafte Ausgestaltungen über die JAVA-Programmiersprache und die virtuelle JAVA-Maschine beschrieben, sie ist aber darauf nicht begrenzt und umfasst stattdessen Systeme, Artikel, Methoden und Vorrichtungen für eine breite Palette an verschiedenen Prozessorumgebungen (sowohl virtuell als auch physisch). Darüber hinaus wurden zwar bestimmte beispielhafte Ausgestaltungen im Hinblick auf Hardware beschrieben, aber geeignete virtuelle Maschinenimplementationen (JAVA-bezogen oder anderweitig) mit einem teilweise verschobenen Objektkennungsspeicher und darauf ansprechenden Barrieren gemäß der obigen Beschreibung beinhalten Implementationen des virtuellen Software-Maschinenanweisungsprozessors wie z. B. einen Bytecode-Interpreter oder einen JIT-Compiler. Diese und andere Variationen, Modifikationen, Zusätze und Verbesserungen fallen in den durch die nachfolgenden Ansprüche definierten Umfang der Erfindung.

Claims (30)

  1. Vorrichtung zur Verwendung in einem Speicherbereinigungssystem zum Verwalten von Memory-Objektinstanz-Einheitlichkeit beim Verschieben eines bestimmten Memory-Objektes in einem Computersystem, das eine begrenzte Pausezeitverschiebung des genannten bestimmten Memory-Objektes bereitstellt, wobei die Vorrichtung Folgendes umfasst: Memory Storage (630), in dem darin gebildete Objekte von jeweiligen FromSpace-(420)Instanzen zu jeweiligen ToSpace-(430)Instanzen davon verschoben werden können, wobei die Vorrichtung Folgendes umfasst: einen teilweise verschobenen Objektkennungsspeicher (144), der so aktualisiert werden kann, dass er ggf. eine FromSpace-Instanz eines bestimmten einen der genannten Objekte (450) identifiziert, für die eine Verschiebung unvollständig ist; und eine Schreibbarriere (740, 840, 940) zu einem speicherorientierten Zugriff eines Mutatorprozesses auf die genannte FromSpace-Instanz des genannten bestimmten Objektes, wobei die genannte Schreibbarriere die Einheitlichkeit zwischen der genannten ToSpace-Instanz und wenigstens einem kopierten Teil (450A) der genannten FromSpace-Instanz durch Rundsenden des genannten speicherorientierten Mutatorprozesszugriffs auf die genannte From- und die genannte To-Instanz wahrt, dadurch gekennzeichnet, dass Logik der genannten Schreibbarriere auf eine Übereinstimmung zwischen einer Zielobjektkennung für den genannten speicherorientierten Mutatorprozesszugriff auf das genannte bestimmte Objekt und dem Inhalt der genannten teilweise verschobenen Objektkennung reagiert.
  2. Vorrichtung nach Anspruch 1, bei der die genannte Schreibbarriere auf eine Übereinstimmung zwischen Inhalt des genannten teilweise verschobenen Objektkennungsspeichers und einer Objektkennung für den genannten speicherorientierten Speicherzugriff reagiert.
  3. Vorrichtung nach Anspruch 1, bei der die genannte Schreibbarriere Schreibbarrierenlogik umfasst, die auf eine Übereinstimmung zwischen Inhalt des genannten teilweise verschobenen Objektkennungsspeichers und einer Objektkennung für den genannten speicherorientierten Speicherzugriff reagiert; und wobei die genannte Schreibbarrierenlogik zu einem teilweise verschobenen Objekt-Trap-Handler nach der genannten Übereinstimmung abfängt.
  4. Vorrichtung nach Anspruch 3, die ferner Folgendes umfasst: eine ToSpace-Instanz-Kennung, auf die der genannte teilweise verschobene Objekt-Trap-Handler zugreifen kann, wobei der genannte teilweise verschobene Objekt-Trap- Handler einen abfangenden speicherorientierten Zugriff zu den genannten ToSpace- und den genannten FromSpace-Instanzen rundsendet.
  5. Vorrichtung nach Anspruch 4, bei der der genannte teilweise verschobene Objektkennungsspeicher die genannte ToSpace-Instanz-Kennung als TO-Feld beinhaltet, auf das der genannte teilweise verschobene Objekt-Trap-Handler zugreifen kann.
  6. Vorrichtung nach Anspruch 4, bei der die genannte ToSpace-Instanz-Kennung einen Teil des genannten Speichers beinhaltet, auf den der genannte teilweise verschobene Objekt-Trap-Handler und ein Speicherbereinigungsprozess zugreifen können.
  7. Vorrichtung nach Anspruch 3, ferner umfassend einen partiellen Kopierpositionsindikator, auf den der genannte teilweise verschobene Objekt-Trap-Handler zugreifen kann, wobei der genannte teilweise verschobene Objekt-Trap-Handler für einen abfangenden speicherorientierten Zugriff auf einen kopierten Teil sowohl zu den genannten ToSpace- als auch zu den genannten FromSpace-Instanzen rundsendet, und wobei der genannte partielle verschobene Objekt-Trap-Handler für einen abfangenden speicherorientierten Zugriff auf einen unkopierten Teil des genannten bestimmten Objektes den genannten speicherorientierten Zugriff zu der genannten FromSpace-Instanz und nicht zu der genannten ToSpace-Instanz leitet.
  8. Vorrichtung nach Anspruch 3, wobei der genannte teilweise verschobene Objektkennungsspeicher eine FromSpace-Instanz-Kennung und einen partiellen Kopierpositionsindikator beinhaltet, um eine Grenze zwischen einem kopierten Teil und einem unkopierten Teil des genannten bestimmten Objektes zu identifizieren; und wobei die genannte Schreibbarriere auf den genannten teilweise verschobenen Objektkennungsspeicher reagiert und auf den genannten teilweise verschobenen Objekt-Trap-Handler nach einem Schreibvorgang auf den genannten kopierten Teil des genannten bestimmten Objektes selektiv abfängt.
  9. Vorrichtung nach Anspruch 1, wobei der genannte teilweise verschobene Objektkennungsspeicher FromSpace- und ToSpace-Instanz-Kennungen beinhaltet; und wobei die genannte Schreibbarriere Schreibbarrierenlogik umfasst, die mit den genannten FromSpace- und den genannten ToSpace-Instanz-Kennungen gekoppelt ist, wobei die genannte Schreibbarrierenlogik auf eine Übereinstimmung zwischen Inhalt der genannten FromSpace-Instanz-Kennung und einer Objektkennung für einen speicherorientierten Memory-Zugriff reagiert, und wobei als Reaktion auf die genannte Übereinstimmung die genannte Schreibbarrierenlogik den genannten speicherorientierten Zugriff zu den genannten ToSpace- und zu den genannten FromSpace-Instanzen rundsendet.
  10. Vorrichtung nach Anspruch 1, bei der die genannte Schreibbarriere Schreibbarrierenlogik umfasst; wobei der genannte teilweise verschobene Objektkennungsspeicher FromSpace- und ToSpace-Instanz-Kennungen und einen partiellen Kopierpositionsindikator umfasst, die jeweils mit der genannten Schreibbarriere gekoppelt sind; wobei die genannte Schreibbarriere für einen speicherorientierten Zugriff auf einen kopierten Teil des genannten bestimmten Objekts Speicherdaten zu den genannten ToSpace- und zu den genannten FromSpace-Instanzen rundsendet, und wobei für einen speicherorientierten Zugriff auf einen unkopierten Teil des genannten bestimmten Objektes die genannte Schreibbarriere die genannten Speicherdaten zu den genannten FromSpace-Instanzen und nicht zu den genannten ToSpace-Instanzen leitet.
  11. Vorrichtung nach Anspruch 1, die ferner Folgendes umfasst: einen Speicherbereinigungsprozess mit ersten Anweisungen, die auf einem Prozessor ausgeführt werden können, der den genannten teilweise verschobenen Objektkennungsspeicher und die genannte Schreibbarriere beinhaltet, wobei die genannten ersten Anweisungen zum inkrementalen Kopieren von Teilen des genannten bestimmten Objekts von der genannten FromSpace-Instanz zu der genannten ToSpace-Instanz; und einen Mutatorprozess mit zweiten Anweisungen, die auf dem genannten Prozessor ablaufen können, zum Durchführen von lastorientierten Memory-Zugriffen und dem genannten speicherorientierten Memory-Zugriff auf das genannte bestimmte Objekt.
  12. Vorrichtung nach Anspruch 1, bei der der genannte teilweise verschobene Objektkennungsspeicher einen partiellen Kopierpositionsindikatorteil beinhaltet, der eine Grenze zwischen einem kopierten Teil und einem unkopierten Teil des genannten bestimmten Objektes anzeigt.
  13. Vorrichtung nach Anspruch 1, bei der die genannte Verschiebung das inkrementale Kopieren des genannten bestimmten Objektes von einem FromSpace-Teil zu einem ToSpace-Teil eines speicherbereinigten Teils des genannten Memory Storage umfasst.
  14. Vorrichtung nach Anspruch 1, bei der der genannte FromSpace und der genannte ToSpace einander überlappen; und wobei die genannte Verschiebung das inkrementale Kopieren des genannten bestimmten Objektes umfasst, um eine Mehrzahl der genannten Objekte in dem genannten Memory Storage zu konsolidieren.
  15. Vorrichtung nach Anspruch 1, wobei der genannte teilweise verschobene Objektkennungsspeicher durch einen Speicherbereinigungsprozess im Einklang mit inkrementalem Kopieren durch diesen aktualisiert wird.
  16. Vorrichtung nach Anspruch 1, die ferner Folgendes umfasst: einen Prozessor, der den genannten teilweise verschobenen Objektkennungsspeicher und die genannte Schreibbarriere ausgestaltet; und Mutatorprozessanweisungen, die in Medien codiert sind, die von dem genannten Prozessor gelesen und von ihm ausgeführt werden können, wobei die genannten Mutatorprozessanweisungen eine Anweisung beinhalten, die dem genannten speicherorientierten Memory-Zugriff entsprechen, und Relokatorprozessanweisungen, die in Medien codiert sind, die von dem genannten Prozessor gelesen und von ihm ausgeführt werden können, wobei die genannten Speicherbereinigungsprozessanweisungen eine Anweisungsfolge zum inkrementalen Kopieren des genannten bestimmten Objektes von der genannten FromSpace-Instanz zu der genannten ToSpace-Instanz beinhalten, um einen Objekt-Referenz-Handle zum Referenzieren der genannten ToSpace-Instanz zu aktualisieren und um den genannten teilweise verschobenen Objektkennungsspeicher im Einklang damit zu halten, wobei die genannte Anweisungsfolge durch die genannten Mutatorprozessanweisungen unterbrochen werden kann.
  17. Vorrichtung nach Anspruch 16, bei der die genannten Relokatorprozessanweisungen so gewählt werden, dass sie einen der folgenden Abläufe durchführen können: generationale Speicherbereinigung, Mark-Sweep-Kompakt-Speicherbereinigung, Kopierspeicherbereinigung und Heap-Konsolidierung mit begrenzter Pausezeit.
  18. Vorrichtung nach Anspruch 16, bei der der genannte Prozessor einen Hardware-Prozessor mit Registerspeicher und Logik umfasst, der den genannten teilweise verschobenen Objektkennungsspeicher und die genannte Speicherbarriere ausgestaltet.
  19. Vorrichtung nach Anspruch 1, die ferner Folgendes umfasst: einen Prozessor, der den genannten teilweise verschobenen Objektkennungsspeicher und die genannte Schreibbarriere ausgestaltet, und Mutatorprozessanweisungen, die in Medien codiert sind, die von dem genannten Prozessor gelesen und von ihm ausgeführt werden können, wobei die genannten Mutatorprozessanweisungen eine Anweisung beinhalten, die dem genannten speicherorientieren Memory-Zugriff entsprechen, und Relokatorprozessanweisungen, die in Medien codiert werden können, die von dem genannten Prozessor gelesen und von ihm ausgeführt werden können, wobei die genannten Speicherbereinigungsprozessanweisungen eine Anweisungsfolge beinhalten, um das genannte bestimmte Objekt von der genannten FromSpace-Instanz zu der genannten ToSpace-Instanz inkremental zu kopieren, um die genannte FromSpace-Instanz referenzierende Zeiger so zu aktualisieren, dass sie die genannte ToSpace-Instanz referenzieren, und um den genannten teilweise verschobenen Objektkennungsspeicher im Einklang damit zu halten, wobei die genannte Anweisungsfolge durch die genannten Mutatorprozessanweisungen unterbrochen werden kann.
  20. Vorrichtung nach Anspruch 1, wobei das genannte bestimmte Objekt ein großes Objekt, ein populäres Objekt oder ein großes und populäres Objekt umfasst.
  21. Vorrichtung nach Anspruch 1, einen Hardware-Prozessor, der den genannten teilweise verschobenen Objektkennungsspeicher und die genannte Schreibbarriere ausgestaltet; eine Kommunikationsbauelement, das mit dem genannten Hardware-Prozessor gekoppelt ist, um Mutatorprozessanweisungen für die Ausführung auf dem genannten Hardware-Prozessor zu empfangen, wobei die genannten Mutatorprozessanweisungen eine erste Anweisung beinhalten, die dem genannten speicherorientierten Memory-Zugriff entspricht; und Medien, die von dem genannten Hardware-Prozessor gelesen werden können, um ausführbare Speicherbereinigungsprozessanweisungen zu codieren, und den genannten Hardware-Prozessor zum inkrementalen Kopieren des genannten Objektes.
  22. Vorrichtung nach Anspruch 1, ferner umfassend einen ersten und einen zweiten Prozessor, die mit dem genannten teilweise verschobenen Objektkennungsspeicher und dem genannten Memory Storage gekoppelt sind, wobei der genannte erste Prozessor die genannte Schreibbarriere beinhaltet; wobei die genannte Verschiebung das inkrementale Kopieren des genannten bestimmten Objektes durch einen Speicherbereinigungsprozess umfasst, der auf dem genannten zweiten Prozessor ausgeführt werden kann, und wobei der genannte speicherorientierte Speicherzugriff einen Schreibzugriff durch einen Mutatorprozess umfasst, der auf dem genannten ersten Prozessor ausgeführt werden kann; und wobei der genannte teilweise verschobene Objektkennungsspeicher von dem genannten Speicherbereinigungsprozess im Einklang mit dem genannten inkrementalen Kopieren des genannten bestimmten Objektes gehalten wird.
  23. Vorrichtung nach Anspruch 22, bei dem der genannte zweite Prozessor ein Universal-Speicherbereinigungsprozessor oder in den genannten Memory Storage integriert ist, wobei der genannte zweite Prozessor und der genannte Memory Storage gemeinsam ein speicherbereinigtes Speichermodul und einen virtuellen Maschinenanweisungsprozessor umfassen.
  24. Vorrichtung nach Anspruch 1, bei dem der genannte teilweise verschobene Objektkennungsspeicher ferner aktualisiert werden kann, um ein zweites der genannten Objekte zu identifizieren, für das die Verschiebung unvollendet ist; und wobei die genannte Vorrichtung ferner einen ersten und einen zweiten Speicherbereinigungsprozessor umfasst, die mit dem genannten teilweise verschobenen Objektkennungsspeicher und dem genannten Memory Storage gekoppelt sind, wobei die Verschiebung des genannten bestimmten und des genannten zweiten Objekts das inkrementale Kopieren davon jeweils durch den genannten ersten und den genannten zweiten Speicherbereinigungsprozessor umfassen.
  25. Verfahren zum Verschieben eines Speicherobjekts mit begrenztem Pausezeiteinfluss auf einen Mutatorprozess. der darauf zugreifen kann, wobei das genannte Verfahren die folgenden Schritte umfasst: Konfigurieren einer Schreibbarriere, die eine teilweise verschobene Objektkennung umfasst, um auf speicherorientierte Zugriffe des genannten Mutatorprozesses auf eine From-Instanz des genannten Memory-Objektes zu reagieren, inkrementales Kopieren des genannten Memory-Objektes von der genannten From-Instanz auf die genannte To-Instanz; während des genannten inkrementalen Kopierens und als Reaktion auf einen ersten der genannten speicherorientierten Zugriffe, Rundsenden des genannten ersten speicherorientierten Zugriffs zu den genannten From- und zu den genannten To-Instanzen, dadurch gekennzeichnet, dass Logik der genannten Schreibbarriere auf eine Übereinstimmung zwischen einer Zielobjektkennung für den genannten speicherorientierten Mutatorprozesszugriff auf das genannte bestimmte Objekt und dem Inhalt der genannten teilweise verschobenen Objektkennung reagiert.
  26. Verfahren nach Anspruch 25, wobei die genannte Schreibbarrierenkonfiguration das Aktualisieren eines teilweise verschobenen Objektkennungsspeichers zum Identifizieren der genannten From-Instanz umfasst; und wobei das genannte Rundsenden als Reaktion auf eine Übereinstimmung zwischen einer Objektkennung für den genannten ersten speicherorientierten Zugriff und Inhalt des genannten teilweise verschobenen Objektkennungsspeichers erfolgt.
  27. Verfahren nach Anspruch 26, wobei die genannte Schreibbarrierenkonfiguration ferner das Aktualisieren eines teilweise verschobenen Objektkennungsspeichers zum Identifizieren der genannten To-Instanz umfasst.
  28. Verfahren nach Anspruch 25, ferner umfassend: Verwalten eines partiellen Kopierpositionsindikators zum Unterscheiden zwischen einem kopierten Teil und einem unkopierten Teil des genannten Memory-Objekts; und während des genannten inkrementalen Kopierens und als Reaktion auf einen zweiten der genannten speicherorientierten Zugriffe auf den genannten unkopierten Teil, Leiten des genannten zweiten speicherorientierten Zugriffs zu der genannten From-Instanz und nicht zu der genannten To-Instanz.
  29. Verfahren nach Anspruch 25, bei dem das genannte Rundsenden von der genannten Schreibbarrieren- oder der genannten Trap-Handler-Software als Reaktion auf einen Trap durch die genannte Schreibbarriere erfolgt.
  30. Computerprogrammprodukt, das ein Medium umfasst, das von einem Prozessor gelesen werden kann, um zu bewirken, dass der genannte Prozessor das Verfahren nach einem der Ansprüche 25–29 ausführt.
DE69825751T 1997-06-26 1998-06-25 Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit einer quelleninstanz eines partiell relokierten objektes assoziiert ist Expired - Lifetime DE69825751T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/883,291 US5873105A (en) 1997-06-26 1997-06-26 Bounded-pause time garbage collection system and method including write barrier associated with a source instance of a partially relocated object
US883291 1997-06-26
PCT/US1998/013478 WO1999000730A1 (en) 1997-06-26 1998-06-25 Bounded-pause time garbage collection system and method including write barrier associated with a source instance of a partially relocated object

Publications (2)

Publication Number Publication Date
DE69825751D1 DE69825751D1 (de) 2004-09-23
DE69825751T2 true DE69825751T2 (de) 2005-07-07

Family

ID=25382334

Family Applications (1)

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

Country Status (6)

Country Link
US (1) US5873105A (de)
EP (1) EP0990207B1 (de)
JP (1) JP3957770B2 (de)
KR (1) KR19990007400A (de)
DE (1) DE69825751T2 (de)
WO (1) WO1999000730A1 (de)

Families Citing this family (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6055612A (en) * 1997-07-11 2000-04-25 Geodesic Systems, Inc. Incremental garbage collector with decommit barrier
US6317872B1 (en) * 1997-07-11 2001-11-13 Rockwell Collins, Inc. Real time processor optimized for executing JAVA programs
US6070173A (en) * 1997-11-26 2000-05-30 International Business Machines Corporation Method and apparatus for assisting garbage collection process within a java virtual machine
JPH11259437A (ja) * 1998-03-12 1999-09-24 Hitachi Ltd 不要バリア命令の削減方式
US6065020A (en) * 1998-05-27 2000-05-16 Microsoft Corporation Dynamic adjustment of garbage collection
US6327701B2 (en) * 1998-09-15 2001-12-04 Sun Microsystems, Inc. Method and apparatus for finding bugs related to garbage collection in a virtual machine
US6317756B1 (en) * 1998-10-07 2001-11-13 International Business Machines Corporation On-the-fly garbage collector
US6279012B1 (en) * 1998-10-13 2001-08-21 Oracle Corporation Reducing the memory footprint of a session duration semispace
GB9825102D0 (en) * 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
GB2345355A (en) * 1998-12-30 2000-07-05 Ibm Garbage collection in a Java virtual machine
US6725241B1 (en) * 1999-03-31 2004-04-20 International Business Machines Corporation Method and apparatus for freeing memory in a data processing system
US6449625B1 (en) * 1999-04-20 2002-09-10 Lucent Technologies Inc. Use of a two-way stack approach to optimize flash memory management for embedded database systems
US6418454B1 (en) * 1999-05-28 2002-07-09 Oracle Corporation Method and mechanism for duration-based management of temporary LOBs
US6286088B1 (en) 1999-06-28 2001-09-04 Hewlett-Packard Company Memory management system and method for relocating memory
US7096238B2 (en) 1999-08-19 2006-08-22 Sun Microsystems, Inc. Dynamic feedback for determining collection-set size
US6349314B1 (en) 1999-09-29 2002-02-19 Motorola, Inc. Adaptive scheduler for mark and sweep garbage collection in interactive systems
SE514318C2 (sv) * 1999-10-28 2001-02-12 Appeal Virtual Machines Ab Förfarande för att effektivisera en databehandlingsprocess vid användning av en virtuell maskin och där ett skräpsamlingsförfarande används
US6800439B1 (en) 2000-01-06 2004-10-05 Affymetrix, Inc. Methods for improved array preparation
US6806361B1 (en) 2000-03-17 2004-10-19 Affymetrix, Inc. Methods of enhancing functional performance of nucleic acid arrays
US6833450B1 (en) 2000-03-17 2004-12-21 Affymetrix, Inc. Phosphite ester oxidation in nucleic acid array preparation
US7157564B1 (en) 2000-04-06 2007-01-02 Affymetrix, Inc. Tag nucleic acids and probe arrays
US6839725B2 (en) * 2000-05-16 2005-01-04 Sun Microsystems, Inc. Dynamic adaptive tenuring of objects
US6799191B2 (en) * 2000-05-16 2004-09-28 Sun Microsystems, Inc. Object sampling technique for runtime observations of representative instances thereof
US7005259B1 (en) 2000-06-01 2006-02-28 Affymetrix, Inc. Methods for array preparation using substrate rotation
US6738875B1 (en) * 2000-07-31 2004-05-18 Microsoft Corporation Efficient write-watch mechanism useful for garbage collection in a computer system
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
US7051056B2 (en) 2000-09-13 2006-05-23 Veritas Operating Corporation Conservative garbage collectors that can be used with general memory allocators
EP1359505B1 (de) * 2000-12-11 2005-11-02 Matsushita Electric Industrial Co., Ltd. Speicherverwaltungsvorrichtung und verfahren
US7216136B2 (en) 2000-12-11 2007-05-08 International Business Machines Corporation Concurrent collection of cyclic garbage in reference counting systems
US6829616B2 (en) 2001-03-26 2004-12-07 International Business Machines Corporation Method, system, and program for implementing a database trigger
US6928460B2 (en) * 2002-07-01 2005-08-09 Sun Microsystems, Inc. Method and apparatus for performing generational garbage collection in a segmented heap
US7174354B2 (en) * 2002-07-31 2007-02-06 Bea Systems, Inc. System and method for garbage collection in a computer system, which uses reinforcement learning to adjust the allocation of memory space, calculate a reward, and use the reward to determine further actions to be taken on the memory space
EP1387273B1 (de) * 2002-07-31 2010-07-21 Texas Instruments Incorporated Überwachungsbasierte bedingte Abfallsammlung zur Verbesserung der Echtzeitleistung
US7539713B2 (en) 2002-11-05 2009-05-26 Sun Microsystems, Inc. Allocation of likely popular objects in the train algorithm
US6999979B2 (en) * 2002-11-05 2006-02-14 Sun Microsystems, Inc. Efficient encoding of references into a collection set
US7035884B2 (en) * 2002-11-05 2006-04-25 Sun Microsystems, Inc. Placement of allocation trains in the train algorithm
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
US7143124B2 (en) * 2002-12-06 2006-11-28 Sun Microsystems, Inc. Detection of dead regions during incremental collection
US7085790B2 (en) * 2002-12-06 2006-08-01 Sun Microsystems, Inc. Advancing cars in trains managed by a 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
US7069280B2 (en) 2002-12-06 2006-06-27 Sun Microsystems, Inc. Collection-tick mechanism for a collector based on the train algorithm
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
US20040128329A1 (en) * 2002-12-31 2004-07-01 International Business Machines Corporation Parallel incremental compaction
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
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
US7096329B2 (en) * 2003-02-27 2006-08-22 Sun Microsystems, Inc. Better placement of objects promoted into a generation managed by 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
US7197521B2 (en) * 2003-11-21 2007-03-27 Intel Corporation Method and system performing concurrently mark-sweep garbage collection invoking garbage collection thread to track and mark live objects in heap block using bit vector
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
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
US7788300B2 (en) * 2004-09-15 2010-08-31 Sap Ag Garbage collection for shared data entities
US7647186B2 (en) 2004-12-07 2010-01-12 Illumina, Inc. Oligonucleotide ordering system
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
US8392900B1 (en) * 2005-03-17 2013-03-05 Hewlett-Packard Development Company, L.P. Methods and systems for barrier reduction in parallel processing systems
US7548940B2 (en) * 2005-06-10 2009-06-16 International Business Machines Corporation Generational real-time garbage collection
GB0512809D0 (en) * 2005-06-23 2005-08-03 Ibm Arrangement and method for garbage collection in a computer system
US7685580B1 (en) * 2005-08-30 2010-03-23 Sun Microsystems, Inc. Method and apparatus for selectively eliminating write barriers in snapshot-at-the beginning concurrent-marking garbage collectors
US7757222B2 (en) * 2005-09-30 2010-07-13 Intel Corporation Generating efficient parallel code using partitioning, coalescing, and degenerative loop and guard removal
US9785549B2 (en) * 2007-04-27 2017-10-10 Microsoft Technology Licensing, Llc Managing object lifetime for native/managed peers
CN101809545B (zh) * 2007-09-25 2012-06-13 国际商业机器公司 存储器管理方法及其设备
US8266190B2 (en) * 2007-09-25 2012-09-11 International Business Machines Corporation Memory management for garbage collection of critical real time threads
US9208081B1 (en) * 2007-11-30 2015-12-08 Oracle America, Inc. Concurrent object management
US20090220169A1 (en) * 2008-02-28 2009-09-03 Microsoft Corporation Image enhancement
US8245005B2 (en) * 2008-03-03 2012-08-14 Microsoft Corporation Probabilistic object relocation
US9110791B2 (en) * 2008-03-03 2015-08-18 Microsoft Technology Licensing, Llc Optimistic object relocation
US20090300030A1 (en) * 2008-05-30 2009-12-03 Microsoft Corporation Large capacity data processing models
US20110264880A1 (en) * 2010-04-23 2011-10-27 Tatu Ylonen Oy Ltd Object copying with re-copying concurrently written objects
US8527559B2 (en) * 2010-04-23 2013-09-03 Clausal Computing Oy Garbage collector with concurrent flipping without read barrier and without verifying copying
US8601036B2 (en) 2011-03-23 2013-12-03 International Business Machines Corporation Handling persistent/long-lived objects to reduce garbage collection pause times
US8825721B2 (en) * 2011-10-03 2014-09-02 Oracle International Corporation Time-based object aging for generational garbage collectors
JP6044181B2 (ja) * 2012-08-24 2016-12-14 富士通株式会社 ガーベジコレクションのための情報処理方法、プログラム及び装置
CN105190565B (zh) * 2013-03-14 2019-01-18 英特尔公司 具有改进的可扩展性的存储器对象引用计数管理
US9535831B2 (en) 2014-01-10 2017-01-03 Advanced Micro Devices, Inc. Page migration in a 3D stacked hybrid memory
US10176093B2 (en) * 2015-06-30 2019-01-08 International Business Machines Corporation Pauseless location and object handle based garbage collection
US9734053B2 (en) 2015-06-30 2017-08-15 International Business Machines Corporation Garbage collection handler to update object pointers
US10180902B2 (en) * 2015-06-30 2019-01-15 International Business Machines Corporation Pauseless location and object handle based garbage collection
GB201704844D0 (en) 2017-03-27 2017-05-10 Microsoft Technology Licensing Llc Manual memory management using lazy patching
US10318415B2 (en) 2017-05-31 2019-06-11 International Business Machines Corporation Garbage collection facility grouping infrequently accessed data units in designated transient memory area
US10459656B1 (en) 2018-06-25 2019-10-29 International Business Machines Corporation Method and apparatus to represent activation frame for pause-less garbage collection
CN111208713B (zh) * 2020-03-17 2022-08-16 合肥芯碁微电子装备股份有限公司 处理曝光图形数据的方法、曝光控制单元和直写式曝光机
CN112463626B (zh) * 2020-12-10 2023-07-11 网易（杭州）网络有限公司 内存泄漏定位方法、装置、计算机设备及存储介质
US11789649B2 (en) 2021-04-22 2023-10-17 Nvidia Corporation Combined on-package and off-package memory system

Family Cites Families (16)

* 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
US5136706A (en) * 1987-04-30 1992-08-04 Texas Instruments Incorporated Adaptive memory management system for collection of garbage in a digital computer
US4807120A (en) * 1987-04-30 1989-02-21 Texas Instruments Incorporated Temporal garbage collector with indirection cells
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
US5463778A (en) * 1989-11-16 1995-10-31 Texas Instruments Incorporated User controlled trap handler
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
EP0990207B1 (de) 2004-08-18
KR19990007400A (ko) 1999-01-25
WO1999000730A1 (en) 1999-01-07
JP3957770B2 (ja) 2007-08-15
US5873105A (en) 1999-02-16
EP0990207A1 (de) 2000-04-05
JP2002506549A (ja) 2002-02-26
DE69825751D1 (de) 2004-09-23

Similar Documents

Publication Publication Date Title
DE69825751T2 (de) Garbage-sammlungs-anordnung und verfahren mit begrenzter pausenzeit und mit einer schreibschranke die mit einer quelleninstanz eines partiell relokierten objektes assoziiert ist
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
DE69836796T2 (de) Datenverarbeiter mit lokalisierter gedächtnisreklamierung
US5857210A (en) Bounded-pause time garbage collection system and method including read and write barriers associated with an instance of a partially relocated object
DE60032694T2 (de) Speicherrückforderungsverfahren
DE60034702T2 (de) Verfahren und vorrichtung zur verbesserung der wirksamkeit von kopierender speicherbereinigung
DE69909021T2 (de) Dynamische Speicherrückforderung ohne Compiler- oder Programmverbinderunterstützung
DE19945992B4 (de) Dynamisch optimierender Objektcode-Übersetzer zur Architekturemulation und dynamisches optimierendes Objektcode-Übersetzungsverfahren
DE69923657T2 (de) Markierung von gespeicherten datenobjekten für garbage-kollektoren
DE69814170T2 (de) Inkrementeller freispeichersammler
Stefanović et al. Age-based garbage collection
DE19959758A1 (de) Bestimmung der Art und der Genauigkeit von lokalen Variablen bei vorhandenen Subroutinen
DE112012000303T5 (de) Dynamische binäre Optimierung
DE69932964T2 (de) Verfahren, System und Rechnerprogrammprodukt zur Initialisierung einer Datenstruktur beim ersten Gebrauch
DE112012000365T5 (de) Inkrementelles Entladen von Klassen in einem auf Bereichen beruhenden Speicherbereiniger
DE102009046444A1 (de) An die Software angepasste Abnutzungsausgleichung
DE10296957T5 (de) Ein Verfahren zum Verwenden nicht-temporaler Streaming-Speicheroperationen zum Verbessern eines Algorithmus zur Sammlung wertloser Daten
Richter Garbage collection: Automatic memory management in the Microsoft .NET Framework
DE112019001821T5 (de) Verfahren und vorrichtung zur wiedergabe eines aktivierungsrahmens für unterbrechungsfreie speicherbereinigung (pause-less garbage collection)
US7062518B2 (en) Efficiently supporting the existence of long trains in a generation managed by the train algorithm
DE60307527T2 (de) Tupleraumoperationen für eine feinkörnige Systemsteuerung
DE10393835T5 (de) Ausführung einer modifizierten Cheney-Abtastung in einer Multithreaded-Verarbeitungsumgebung
KR100576904B1 (ko) 가비지수집페이지경계횡단포인터스토어를트랩하기위한기록배리어시스템및방법
EP1530131B1 (de) Beschleunigtes Referenzfinden für eine automatische Speicherbereinigung (Garbage Collection)
EP0433489A1 (de) Verfahren zur Bereinigung eines Speichers von Objekten, auf die während eines Programmlaufs nicht mehr zugegriffen werden kann

Legal Events

Date Code Title Description
8364 No opposition during term of opposition