DE112018005404T5 - Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers - Google Patents

Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers Download PDF

Info

Publication number
DE112018005404T5
DE112018005404T5 DE112018005404.7T DE112018005404T DE112018005404T5 DE 112018005404 T5 DE112018005404 T5 DE 112018005404T5 DE 112018005404 T DE112018005404 T DE 112018005404T DE 112018005404 T5 DE112018005404 T5 DE 112018005404T5
Authority
DE
Germany
Prior art keywords
processing
domain
locality
storage unit
memory
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.)
Pending
Application number
DE112018005404.7T
Other languages
English (en)
Inventor
Michael Karl Gschwind
Jonathan Bradbury
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112018005404T5 publication Critical patent/DE112018005404T5/de
Pending legal-status Critical Current

Links

Images

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
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • 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
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0685—Hybrid storage combining heterogeneous device types, e.g. hierarchical storage, hybrid arrays
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811—Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/25—Using a specific main memory architecture
    • G06F2212/254—Distributed memory
    • G06F2212/2542—Non-uniform memory access [NUMA] architecture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/28—Using a specific disk cache architecture
    • G06F2212/283—Plural cache memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/602—Details relating to cache prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/651—Multi-level translation tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/654—Look-ahead translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G06F2212/681—Multi-level TLB, e.g. microTLB and main TLB
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/70—Details relating to dynamic memory management
    • G06F2212/702—Conservative garbage collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Memory System (AREA)

Abstract

Die Verarbeitung innerhalb einer Datenverarbeitungsumgebung wird vereinfacht, indem Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung ermittelt werden. Sobald sie ermittelt wurden, können die Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur zwischengespeichert werden, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu einer Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft die Vereinfachung des Zugriffs auf Lokalitätsdomäneninformationen eines Speichers.
  • HINTERGRUND
  • In einem System mit nicht einheitlichem Speicherzugriff (NUMA, non-uniform memory access) sind Prozessoren üblicherweise über Bücher (wie beispielsweise Ablagebretter oder Ablagefächer) verteilt, wobei jedes Buch einen oder mehrere mit dem Prozessor verbundene Speicher enthält, die lokal zu dem Buch gehören. Die Bücher sind über ein Netzwerk miteinander verbunden, so dass Prozessoren auf einem Buch auch auf Speicher auf anderen Büchern zugreifen können.
  • Prozessoren in NUMA-Systemen können schnell und effizient auf lokalen Speicher zugreifen. Wenn ein Prozessor jedoch auf Remote-Speicher auf einem anderen Buch zugreifen muss, kommt es zu einer Verzögerung, die als Latenzzeit bezeichnet wird. Es gibt auch Probleme mit der Bandbreite über das Netzwerk, das die Bücher miteinander verbindet.
  • KURZDARSTELLUNG
  • Durch die Bereitstellung eines Computerprogrammprodukts, um die Verarbeitung innerhalb einer Datenverarbeitungsumgebung zu vereinfachen, werden Unzulänglichkeiten nach dem Stand der Technik angegangen und zusätzliche Vorteile bereitgestellt. Das Computerprogrammprodukt enthält ein durch einen Computer lesbares Speichermedium, das durch eine Verarbeitungsschaltung gelesen werden kann und Instruktionen speichert, die, wenn sie ausgeführt werden, ein Verfahren durchführen. Das Verfahren umfasst zum Beispiel das Ermitteln von Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung; und das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu einer Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören. Vorteilhafterweise vereinfacht das Zwischenspeichern von ermittelten Lokalitätsdomäneninformationen einer Speichereinheit in einer Datenstruktur die Verarbeitung innerhalb der Datenverarbeitungsumgebung, indem der Verarbeitungsaufwand verringert wird, um die Lokalitätsdomäneninformationen später abzurufen, und folglich wird die Systemperformanz verbessert.
  • In einer oder mehreren Ausführungsformen ist die Speichereinheit eine virtuelle Speichereinheit und das Ermitteln umfasst das Umsetzen der virtuellen Speichereinheit in eine reale Speichereinheit und das Verwenden der realen Speichereinheit, um die Lokalitätsdomäneninformationen aus einer Konfigurationsmatrix abzurufen, die Systemstandortinformationen über physische Komponenten der Datenverarbeitungsumgebung enthält.
  • In einer oder mehreren Ausführungsformen kann das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Konfigurationsmatrix-Cachespeicher umfassen, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört. In einer oder mehreren weiteren Ausführungen kann das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Adressumsetzpufferspeicher der Datenverarbeitungsumgebung umfassen.
  • In einer oder mehreren Ausführungsformen handelt es sich bei der Datenverarbeitungsumgebung um eine Datenverarbeitungsumgebung mit nicht einheitlichem Speicherzugriff (NUMA), und die Lokalitätsdomäneninformationen der Speichereinheit zu der Verarbeitungsfunktion umfassen Informationen, die eine bestimmte Verarbeitungsdomäne der NUMA-Datenverarbeitungsumgebung kennzeichnen, zu der die Speichereinheit eine lokalitätsbasierte Affinität hat.
  • In einer oder mehreren Ausführungen umfasst das Verfahren des Weiteren die Feststellung, ob die Speichereinheit Lokalitätsaffinität zu einer Verarbeitungsdomäne einer Vielzahl von Verarbeitungsdomänen der Datenverarbeitungsumgebung hat. Die Feststellung kann das Abrufen der Lokalitätsdomäneninformationen der Speichereinheit aus der Datenstruktur für einen Vergleich der Lokalität der Verarbeitungsdomäne innerhalb der Datenverarbeitungsumgebung umfassen. In einem oder mehreren Beispielen handelt es sich bei der Datenstruktur um einen Konfigurationsmatrix-Cachespeicher, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört, oder um einen Matrix-Adressumsetzpufferspeicher der Datenverarbeitungsumgebung. Des Weiteren kann das Verfahren in einem oder mehreren Beispielen das Setzen eines Anzeigers umfassen, der eine lokale Affinität angibt, wenn die Lokalitätsdomäneninformationen der Speichereinheit mit der Lokalität der Verarbeitungsdomäne übereinstimmen. In einer oder mehreren zusätzlichen Ausführungsformen kann das Verfahren basierend darauf, dass die Speichereinheit Lokalitätsaffinität zu der Verarbeitungsdomäne hat, das Durchführen durch die Verarbeitungsdomäne eines Garbage-Collection-Prozesses auf der Speichereinheit umfassen.
  • Computersysteme und durch einen Computer ausgeführte Verfahren, die sich auf einen oder mehrere Aspekte beziehen, werden ebenfalls hierin beschrieben und beansprucht. Des Weiteren werden Dienste, die sich auf einen oder mehrere Aspekte beziehen, ebenfalls hierin beschrieben und gegebenenfalls hierin beansprucht.
  • Zusätzliche Merkmale und Vorteile werden durch die Techniken der vorliegenden Erfindung realisiert. Weitere Ausführungsformen und Aspekte der Erfindung werden hierin ausführlich beschrieben und als ein Teil der beanspruchten Erfindung betrachtet.
  • Figurenliste
  • Ein oder mehrere Aspekte der vorliegenden Erfindung werden in den Ansprüchen am Ende der Beschreibung besonders hervorgehoben und gesondert als Beispiele beansprucht. Die vorstehenden und weitere Objekte, Merkmale und Vorteile der Erfindung gehen aus der folgenden ausführlichen Beschreibung in Zusammenschau mit den beiliegenden Zeichnungen hervor, bei denen:
    • 1A ein Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 1B weitere Einzelheiten eines Buchs (wie zum Beispiel eines Ablagefachs, eines Ablagebretts, eines Servers usw.) von 1A gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 2 ein Beispiel einer Speicherhierarchie eines Buchs von 1A gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 3 weitere Einzelheiten einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • die 4A bis 4C Speicherlokalität in Bezug auf verschiedene Ebenen der Systemarchitektur einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellen;
    • die 5A und 5B alternative Ausführungen von Garbage-Collection-Arbeitswarteschlangen in einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellen;
    • 6 ein weiteres Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 7A ein Beispiel einer Adressumsetzung darstellt;
    • 7B ein weiteres Beispiel einer Adressumsetzung darstellt;
    • 7C ein Beispiel eines Adressumsetzpufferspeichers (TLB, translation lookaside buffer), der Lokalitätsdomäneninformationen von Speichereinheiten zwischenspeichert, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 8 eine einzelne Ausführungsform einer Adressumsetzungseinrichtung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 9 ein vereinfachtes Schema eines Beispiels einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 10A eine einzelne Ausführungsform einer load_domain-Instruktion gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 10B eine einzelne Ausführungsform der Verarbeitung entsprechend einer load_domain-Instruktion gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 11 eine alternative Ausführungsform der Verarbeitung, um Lokalitätsdomäneninformationen einer Speichereinheit innerhalb einer Datenverarbeitungsumgebung zu erhalten, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 12 eine weitere Ausführungsform eines Prozesses, um Lokalitätsdomäneninformationen einer Speichereinheiten zu erhalten, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 13A eine einzelne Ausführungsform einer Speicherzugriffsverarbeitung in Kombination mit dem Zwischenspeichern von Lokalitätsdomäneninformationen innerhalb eines Adressumsetzpufferspeichers (TLB) gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 13B eine weitere Ausführungsform der Verarbeitung von 13A für das Zugreifen auf den Speicher und das Verwalten von Lokalitätsdomäneninformationen, wobei ein TLB-Fehler vorliegt und sich die Domäneninformationen gerade nicht im Adressumsetzpufferspeicher befinden, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 14A eine einzelne Ausführungsform einer is_local domain-Instruktion gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 14B eine einzelne Ausführungsform der Verarbeitung entsprechend einer is_local_domain-Instruktion, um festzustellen, ob eine Speichereinheit (zum Beispiel, um sich einer Garbage-Collection zu unterziehen) lokal zu einer aktuellen Verarbeitungsdomäne gehört, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 15A eine einzelne Ausführungsform einer Speichermanager-Initialisierungsverarbeitung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 15B eine alternative Ausführungsform einer Speichermanager-Initialisierungsverarbeitung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 16 eine einzelne Ausführungsform der Verarbeitung einer Speicherzuordnungsanforderung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 17 eine einzelne Ausführungsform einer auf eine Speicherkomprimierung bezogenen Verarbeitung, die zum Beispiel zu einer Garbage-Collection-Verarbeitung gehört, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 18 eine einzelne Ausführungsform einer auf eine Speicherfreigabe bezogenen Verarbeitung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • die 19A bis 19B eine einzelne Ausführungsform zur Vereinfachung der Verarbeitung innerhalb einer Datenverarbeitungsumgebung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung darstellen;
    • 20A ein weiteres Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung darstellt;
    • 20B weitere Einzelheiten des Speichers von 20A darstellt;
    • 21 eine einzelne Ausführungsform einer Cloud-Computing-Umgebung darstellt; und
    • 22 ein Beispiel von Abstraktionsmodellschichten darstellt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Aspekte der vorliegenden Erfindung und bestimmte Merkmale, Vorteile und Einzelheiten der Erfindung werden nachstehend unter Bezugnahme auf das/die in den beiliegenden Zeichnungen veranschaulichte(n) nicht abschließende(n) Beispiel(e) vollständiger erklärt. Beschreibungen von hinlänglich bekannten Datenverarbeitungssystemen, Einheiten, Verarbeitungstechniken usw. werden weggelassen, um die Erfindung im Einzelnen nicht unnötig intransparent zu machen. Es sollte jedoch klar sein, dass die ausführliche Beschreibung und das/die spezifische(n) Beispiel(e) zwar Aspekte der Erfindung angeben, sie jedoch lediglich zur Veranschaulichung und nicht zur Einschränkung angegeben werden. Verschiedene Ersetzungen, Änderungen, Hinzufügungen und/oder Neuanordnungen im Rahmen des Wesens und/oder Umfangs der zugrunde liegenden erfindungsgemäßen Konzepte gehen für den Fachmann aus dieser Offenbarung hervor. Es sei weiter angemerkt, dass zahlreiche erfindungsgemäße Aspekte und Merkmale hierin offenbart werden und jeder offenbarte Aspekt bzw. jedes offenbarte Merkmal, sofern nicht unvereinbar, mit jedem anderen offenbarten Aspekt bzw. Merkmal wie zum Beispiel von einer bestimmten Anwendung gewünscht kombinierbar ist, um die Verarbeitung innerhalb einer Datenverarbeitungsumgebung zu vereinfachen, wie etwa, um die affinitätsdomänenbasierte Verarbeitung innerhalb einer Datenverarbeitungsumgebung zu vereinfachen.
  • Die veranschaulichenden Ausführungsformen können unter Verwendung von bestimmtem Code, bestimmten Designs, Architekturen, Protokollen, Layouts, schematischen Darstellungen oder Werkzeugen lediglich beispielhaft und nicht zur Einschränkung beschrieben werden. Des Weiteren werden die veranschaulichenden Ausführungsformen in einigen Fällen beschrieben, wobei bestimmte Software, Werkzeuge und Datenverarbeitungsumgebungen lediglich als Beispiel verwendet werden, damit die Beschreibung klarer wird. Die veranschaulichenden Ausführungsformen können in Verbindung mit anderen vergleichbaren oder einem ähnlichen Zweck dienenden Strukturen, Systemen, Anwendungen oder Architekturen verwendet werden. Eine veranschaulichende Ausführungsform kann in Hardware, Software oder einer Kombination daraus ausgeführt sein.
  • Die Beispiele in dieser Offenbarung werden lediglich verwendet, damit die Beschreibung klarer wird und stellen keine Einschränkung der veranschaulichenden Ausführungsformen dar. Zusätzliche Daten, Operationen, Aktionen, Aufgaben, Aktivitäten und Manipulationen sind aus dieser Offenbarung vorstellbar und diese werden im Rahmen der veranschaulichenden Ausführungsformen in Betracht gezogen.
  • Bei jedweden hierin aufgeführten Vorteilen handelt es sich nur um Beispiele und sie sind nicht als Einschränkung der veranschaulichenden Ausführungsformen gedacht. Zusätzliche oder andere Vorteile können durch bestimmte veranschaulichende Ausführungsformen realisiert werden. Darüber hinaus kann eine bestimmte veranschaulichende Ausführungsform über einige, alle oder keine der hierin aufgeführten Vorteile verfügen.
  • Garbage-Collection ist ein automatischer Speicherverwaltungsprozess, der Dateneinheiten wie beispielsweise Objekte, die nicht mehr referenziert werden, im Speicher kennzeichnet und diese Objekte freigibt. Um ungenutzten Speicher zu erkennen, scannt ein Garbage-Collection-Prozess üblicherweise den Satz von dynamisch zugeordneten Datenelementen bzw. den Heap, und stellt für jede Speicherposition fest, ob irgendwo im Speicher der Anwendung eine Nutzung dieser Position erkennbar ist. Garbage-Collection kann einen beträchtlichen Teil der gesamten Verarbeitungszeit in einem Programm in Anspruch nehmen und sich folglich erheblich auf die Performanz auswirken. Des Weiteren kann ein Garbage-Collection-Speicherscan zu unerwünscht langen Pausen des eigentlichen Anwendungsprogramms (der „Mutationsfunktion“) führen. Dieser Umstand kann in bestimmen Systemarchitekturen noch stärker hervortreten, zum Beispiel bei einer Architektur mit nicht einheitlichem Speicherzugriff, die in heutigen Server-Designs üblich ist, bei denen Untergruppen von Speicherpositionen für einen Satz von Prozessoren schneller sind als für einen anderen Satz von Prozessoren.
  • Daher wird gemäß einem oder mehreren Aspekten eine Möglichkeit bereitgestellt, um eine affinitätsdomänenbasierte Garbage-Collection zu vereinfachen. In einer oder mehreren Ausführungen wird hierin eine affinitisierte Garbage-Collection-Verarbeitung basierend auf einer von Adressen abgeleiteten Affinität offenbart.
  • Ein Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung wird zunächst unter Bezugnahme auf 1A beschrieben. In einem Beispiel beruht eine Datenverarbeitungsumgebung 100 auf der von der International Business Machines Corporation, Armonk, New York, USA, angebotenen z/Architecture®. Eine einzelne Ausführungsform der z/Architecture ist in „z/Architecture Principles of Operation“, IBM-Publikation Nr. SA22-7832-10, März 2015, beschrieben, die hiermit in ihrer Gesamtheit durch Bezugnahme hierin übernommen wird. Es sei angemerkt, dass z/ARCHITECTURE® ein eingetragenes Warenzeichen der International Business Machines Corporation, Armonk, New York, USA, ist.
  • In einem weiteren Beispiel kann die Datenverarbeitungsumgebung auf der von der International Business Machines Corporation, Armonk, New York, angebotenen Power Architecture® beruhen. Eine einzelne Ausführungsform der Power Architecture ist in „Power ISA™ Version 2.07B,“ International Business Machines Corporation, 9. April 2015, beschrieben, die hiermit in ihrer Gesamtheit durch Bezugnahme Bestandteil hiervon ist. Es sei des Weiteren angemerkt, dass POWER ARCHITECTURE® ein eingetragenes Warenzeichen der International Business Machines Corporation, Armonk, New York, USA, ist.
  • Die Datenverarbeitungsumgebung kann auch auf anderen Architekturen beruhen, darunter, ohne darauf beschränkt zu sein, den x86-Architekturen von Intel. Andere Beispiele gibt es ebenfalls.
  • In einem Beispiel enthält die Datenverarbeitungsumgebung 100 eine Vielzahl von Büchern (d.h. Ablagefächern, Ablagebrettern usw.) 102. Ein Buch enthält ein oder mehrere zentrale Verarbeitungs-(CP-)Cluster 104 (die auch als Knoten bezeichnet werden) und einen Systemcontroller (SC) 106 (z.B. SC-Chip). Der Systemcontroller verbindet die Bücher 102 miteinander und kann von einem oder mehreren CP-Clustern getrennt und/oder Teil von einem oder mehreren CP-Clustern sein. Weitere Einzelheiten in Bezug auf das Buch 102 werden unter Bezugnahme auf 1B beschrieben.
  • Wie gezeigt ist, enthält das Buch 102 in einem Beispiel eine Vielzahl von (z.B. 2) zentralen Verarbeitungsclustern 104. Ein zentrales Verarbeitungscluster 104 enthält eine Vielzahl von zentralen Prozessorchips 110, von denen jeder mit dem Systemcontroller 106 verbunden ist. Ein zentraler Prozessorchip 110 enthält einen oder mehrere Kerne 120 (die auch als Prozessoren oder zentrale Verarbeitungseinheiten (CPUs) bezeichnet werden), wie z.B. acht Kerne pro Chip. Überdies ist der zentrale Prozessorchip 110 in einem Beispiel mit z.B. einem oder mehreren Dual Inline Memory Modules (DIMMs) 122 verbunden, die Speicher zur Verwendung durch das CP-Cluster 104 bereitstellen.
  • Das CP-Cluster 104 verwendet Hauptspeicher sowie Speichercaches, um die Verarbeitung zu vereinfachen. Ein Beispiel einer von dem CP-Cluster 104 genutzten Speicherhierarchie wird unter Bezugnahme auf 2 beschrieben. In einem Beispiel enthält eine Speicherhierarchie 200 einen Hauptspeicher 202; einen gemeinsam genutzten L4-Cachespeicher 204; einen oder mehrere gemeinsam genutzte L3-Cachespeicher 206; einen oder mehrere private L2-Cachespeicher 208; und einen oder mehrere private L1-Cachespeicher 210 in einem Prozessor 120. In dieser beispielhaften Ausführung ist der L4-Cachespeicher 204 Teil des Systemcontrollers 106, der Anschlussmöglichkeiten zu den anderen Büchern bereitstellt. Zwar ist hierin eine beispielhafte Speicherhierarchie beschrieben, doch sind andere Beispiele möglich.
  • Weitere Einzelheiten in Bezug auf ein Beispiel des CP-Clusters 104 werden unter Bezugnahme auf 3 beschrieben. Das CP-Cluster 104 ist in einem Beispiel in Form einer Universal-Datenverarbeitungseinheit gezeigt. Das CP-Cluster 104 kann, ohne darauf beschränkt zu sein, einen oder mehrere Prozessoren oder Verarbeitungseinheiten 304 (z.B. den Kern 120), einen Speicher 306 (der als Hauptspeicher oder Massenspeicher, als Beispiele, bezeichnet wird, z.B. den Speicher 202) und eine oder mehrere Ein-/Ausgabe-(E/A-)Schnittstellen 308 enthalten, die über einen oder mehrere Busse und/oder andere Verbindungen 310 miteinander verbunden sind.
  • Der Bus 310 stellt eine oder mehrere von beliebigen Busstrukturen von mehreren Arten von Busstrukturen dar, darunter einen Speicherbus oder einen Speichercontroller, einen peripheren Bus, einen Accelerated Graphics Port und einen Prozessor- oder lokalen Bus, der beliebige von verschiedensten Busarchitekturen verwendet. Beispielhaft und nicht darauf beschränkt gehören zu solchen Architekturen der lokale Bus „Industry Standard Architecture (ISA)“, „Micro Channel Architecture (MCA)“, „Enhanced ISA (EISA)“, „Video Electronics Standards Association (VESA)“ und der „Peripheral Component Interconnect (PCI)“.
  • Der Speicher 306 kann zum Beispiel einen Cachespeicher 320, wie etwa einen gemeinsam genutzten Cachespeicher (z.B. den L4-Cachespeicher 204 und/oder den L3-Cachespeicher 206) enthalten und/oder mit diesem verbunden sein, der mit lokalen Cachespeichern 322 (z.B. dem L2-Cachespeicher 208 und/oder dem L1-Cachespeicher 210) der Prozessoren 304 als Teil einer Cachespeicher-Hierarchie verbunden sein kann, die ein komplexes System von Bussen enthält, welche die Prozessoren, die Chips, die CP-Cluster und einen oder mehrere Speichercontroller in einem aus mehreren Büchern bestehenden System miteinander verbinden. Des Weiteren kann der Speicher 306 ein oder mehrere Programme oder Anwendungen 330, ein Betriebssystem 332 und eine oder mehrere durch einen Computer lesbare Programminstruktionen 334 sowie Garbage-Collection-Logik 336 oder -Instruktionen enthalten. In einer oder mehreren Ausführungsformen können die durch einen Computer lesbaren Programminstruktionen 334 so konfiguriert werden, dass sie Funktionen von Ausführungsformen von Aspekten der Erfindung ausführen.
  • Das CP-Cluster 104 kann auch über z.B. E/A-Schnittstellen 308 mit einer oder mehreren externen Einheiten 340, einer oder mehreren Netzschnittstellen 342 und/oder einer oder mehreren Datenspeichereinheiten 344 Daten austauschen. Zu beispielhaften externen Einheiten gehören ein Benutzerterminal, ein Bandlaufwerk, eine Zeigereinheit, ein Bildschirm usw. Die Netzschnittstelle 342 ermöglicht dem CP-Cluster 104 den Datenaustausch mit einem oder mehreren Netzwerken, wie beispielsweise einem lokalen Netz (LAN, local area network), einem allgemeinen Weitverkehrsnetz (WAN, wide area network) und/oder einem öffentlichen Netz (z.B. dem Internet), die eine Übertragung mit anderen Datenverarbeitungseinheiten oder -systemen bereitstellen.
  • Die Datenspeichereinheit 344 kann ein oder mehrere Programme 346, eine oder mehrere durch einen Computer lesbare Programminstruktionen 348 und/oder Daten usw. speichern. Die durch einen Computer lesbaren Programminstruktionen können so konfiguriert werden, dass sie Funktionen von Ausführungsformen von Aspekten der Erfindung ausführen.
  • Das CP-Cluster 104 kann auswechselbare/nicht auswechselbare, flüchtige/nicht flüchtige Speichermedien eines Computersystems enthalten und/oder damit verbunden sein. Zum Beispiel kann es einen nicht auswechselbaren, nicht flüchtigen magnetischen Datenträger (der üblicherweise als „Festplattenlaufwerk“ bezeichnet wird), ein Magnetplattenlaufwerk, um von einer auswechselbaren, nicht flüchtigen Magnetplatte (z.B. einer „Diskette“) zu lesen und auf sie zu schreiben, und/oder ein optisches Plattenlaufwerk, um von einer auswechselbaren, nicht flüchtigen optischen Platte, wie beispielsweise einem CD-ROM, DVD-ROM oder einem anderen optischen Medium zu lesen oder auf es zu schreiben, enthalten und/oder damit verbunden sein. Es sollte klar sein, dass andere Hardware- und/oder Software-Komponenten in Verbindung mit dem CP-Cluster 104 verwendet werden könnten. Zu Beispielen gehören, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Anordnungen von Festplattenlaufwerken, RAID-Systeme, Bandlaufwerke und Speichersysteme zur Datenarchivierung usw.
  • Das CP-Cluster 104 kann mit zahlreichen anderen Mehrzweck- oder Spezialdatenverarbeitungssystemumgebungen oder -konfigurationen betrieben werden. Zu Beispielen für hinlänglich bekannte Datenverarbeitungssysteme, -umgebungen und/oder - konfigurationen, die für eine Verwendung mit dem CP-Cluster 104 geeignet sein können, gehören, ohne darauf beschränkt zu sein, Personal-Computer-(PC-)Systeme, Server-Computersysteme, Thin Clients, Thick Clients, tragbare oder Laptop-Einheiten, Mehrprozessorsysteme, auf einem Mikroprozessor beruhende Systeme, Aufsatzgeräte (Set-Top-Boxen), programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme sowie verteilte Cloud-Computing-Umgebungen, die beliebige der vorstehenden Systeme oder Einheiten enthalten, und dergleichen.
  • Die vorstehend in Verbindung mit den 1A bis 3 beschriebene Datenverarbeitungsumgebung ist ein Beispiel einer Datenverarbeitungsumgebung oder eines Datenverarbeitungssystems mit nicht einheitlichem Speicherzugriff (NUMA). Ein nicht einheitlicher Speicherzugriff (NUMA) ist ein im Mehrprozessbetrieb verwendetes Computerspeicher-Design, bei dem die Speicherzugriffszeit von der auf den Prozessor bezogenen Speicherposition abhängt. Unter NUMA kann ein Prozessor auf den eigenen lokalen Speicher des Prozessors schneller zugreifen als auf einen nicht lokalen Speicher (d.h. einen Speicher, der lokal zu einem anderen Prozessor gehört, oder einen zwischen Prozessoren gemeinsam genutzten Speicher). In einer solchen Datenverarbeitungsumgebung wird auf den gesamten NUMA-Speicher in einem einzigen gemeinsamen globalen Adressraum durch die Prozessoren in dem System zugegriffen, ungeachtet dessen, ob der Speicher für einen bestimmten Prozessor ein lokaler Speicher oder ein nicht lokaler Speicher ist. Wir vorstehend erklärt wurde, sind die Prozessoren in einer NUMA-Datenverarbeitungsumgebung über Bücher (z.B. Ablagefächer oder Ablagebretter) verteilt, und jedes Buch kann einen oder mehrere mit dem Prozessor verbundene Speicher enthalten, die lokal zu diesem Buch gehören. Die Bücher sind durch ein Netzwerk miteinander verbunden, wie in den 1A und 1B gezeigt ist, so dass Prozessoren auf einem Buch auf Speicher auf anderen Büchern zugreifen können. Wie erwähnt wurde, kann Garbage-Collection innerhalb solcher Datenverarbeitungsumgebungen zeitaufwendig sein und sich stark auf die Systemperformanz auswirken. Wie ebenfalls erwähnt wurde, kann ein Speicherscan als Teil eines Garbage-Collection-Prozesses rechenintensiv sein, was möglicherweise zu unerwünschten langen Pausen des eigentlichen Anwendungsprogramms (der „Mutationsfunktion“) führt. Dies kann in Datenverarbeitungsumgebungen wie zum Beispiel einem System mit nicht einheitlichem Speicherzugriff verstärkt werden, das in heutigen Server-Designs üblich ist, bei dem Untergruppen von Speicherpositionen für einen Satz von Prozessoren schneller sind als für andere Sätze von Prozessoren. Wie hierin offenbart, ist es daher wünschenswert, den Speicherscan des Anwendungs-Heaps nach Möglichkeit für jeden Satz von Speicherpositionen mit dem/den Prozessor(en) durchzuführen, der bzw. die den schnellsten Zugriff auf diese Speicherpositionen hat/haben.
  • Ein Ansatz für eine solche affinitisierte Garbage-Collection wäre, Heapspeicher für jeden Software-Ausführungsthread aus einem Speicherpool zuzuordnen, der bekanntermaßen mit einem bestimmten Prozessorkern eng verbunden ist, und den Software-Thread an einen Hardware-Ausführungsthread auf demselben Kern zu binden. Nachteilig ist, dass eine solche Organisation erhebliche invasive Änderungen in dem Software-Stack erforderlich machen würde. Zum Beispiel würde sie eine Fähigkeit erfordern, eine Speicherzuordnung in einem an einen bestimmten Prozessor angeschlossenen Speicher anzufordern, was entsprechende Anforderungen von einer Anwendung an das Betriebssystem und des Weiteren von einem Betriebssystem an den Hypervisor einschließen würde. Auch würde sie das Binden von Speicher, der Prozessorknoten so zugeordnet ist, erfordern, das heißt, wenn ein Prozessor Speicher auslagert und später Speicher einlagert, erfolgt das Einlagern in Speicher, der demselben Prozessor zugeordnet ist, wie ursprünglich angefordert. Des Weiteren würde sie das Binden eines Software-Threads an einen Hardware-Prozessor erfordern, so dass sich die Ausführung, sobald Speicher zugeordnet wurde, der an einen Prozessor angeschlossen ist, weiterhin auf diesem Kern befindet, was Planungsfreiheit sowohl für das Betriebssystem als auch den Hypervisor einschränkt. Bei einer solchen Architektur gibt es zugeordnete Heaps H(T(n)) für mehrere Threads T(N), und jede Anwendung eines Thread T(n) ordnet Heapspeicher von H(T(n)) zu, und bei Durchführung einer Garbage-Collection führt ein T(n) zugeordneter Garbage-Collection-Worker-Thread den Scan des Heaps durch. Leider wäre ein solcher Ansatz unerwünscht restriktiv bei der Fähigkeit, Speicher frei zuzuordnen, um Ausführungsthreads frei zuzuordnen, und übermäßig invasiv in Hinblick darauf, dass Änderungen an Systemschnittstellen notwendig wären, was sowohl zu geringerer Systemeffizienz als auch einer Unfähigkeit führen würde, eine solche affinitisierte Garbage-Collection-Verarbeitung auf ältere (Legacy-)Systeme anzuwenden. Daher ist ein anderer Ansatz für die Durchführung einer effizienteren Garbage-Collection, wie beispielsweise in älteren Systemen, erwünscht, während gleichzeitig auch die Freiheit für das Betriebssystem und den Hypervisor erhalten bleibt, Entscheidungen hinsichtlich einer effizienten Ressourcenzuordnung zu treffen.
  • Vorteilhafterweise wird hierin ein affinitisierter Garbage-Collection-Prozess basierend auf einer von Adressen abgeleiteten Affinität offenbart. Gemäß einem oder mehreren Aspekten werden ein Verfahren, ein System und ein Computerprogrammprodukt bereitgestellt, um das Zuordnen von Garbage-Collection-Operationen zu (einem) Prozessor(en) zu vereinfachen, der am engsten mit der Speicherregion verbunden ist, in der die Garbage-Collection-Operationen zugeordnet werden (der hierin auch als die Affinitätsdomäne des Prozessors bezeichnet wird). Man beachte, dass in der hierin bereitgestellten Beschreibung Lokalitätsdomäne, Affinitätsdomäne oder Domäne austauschbar verwendet werden können. In einer oder mehreren Ausführungsformen kann die Lokalitätsdomäne über eine Vielzahl von Speicherpositionen, Einheiten usw. verfügen und eine Domäne sein, die zum Beispiel ein gemeinsames Zugriffsmerkmal oder -merkmale hat, etwa hinsichtlich der Zugriffsperformanz oder Latenzzeit in Bezug auf einen oder mehrere Prozessoren. In einer oder mehreren Ausführungen kann eine Lokalitätsdomäne durch eine Nummer oder eine Beschreibung gekennzeichnet werden. Abhängig von der Beschreibung kann Lokalitätsdomäne auch den bestimmten Speicher bedeuten, der für einen bestimmten Prozessor oder einen Satz von Prozessoren am lokalsten ist.
  • Beispielhalber und wie hierin weiter erklärt, kann der affinitisierte Garbage-Collection-Prozess die Feststellung umfassen, welcher Affinitäts- oder Lokalitätsdomäne eine Speicherregion zugeordnet ist, und basierend auf der festgestellten Lokalitätsdomäne kann ein Test durchgeführt werden, um festzustellen, ob die Lokalitätsdomäne der Lokalitätsdomäne eines bestimmten (z.B. vorhandenen) Prozessors entspricht, der berücksichtigt wird. Basierend darauf, dass die Lokalitätsdomänen übereinstimmen, wird eine Garbage-Collection-Operation auf diesem bestimmten Prozessor eingeleitet (oder es wird angezeigt, dass sie eingeleitet werden soll) (entweder sofort oder indem die Garbage-Collection-Operation in eine Arbeitswarteschlange gestellt wird (z.B. eine Garbage-Collection-Arbeitswarteschlange) für diesen bestimmten Prozessor). Andernfalls kann die Speicherregion von einem anderen Prozessor, der über die passende Lokalitätsdomäne verfügt, und nicht von dem bestimmten (z.B. dem aktuellen) Prozessor gescannt werden.
  • Verschiedenste Ausführungsformen werden hierin erörtert. In einer einzelnen Ausführungsform wird eine einheitliche Arbeitswarteschlange erörtert, die ältere Garbage-Collection-Arbeitswarteschlangen widerspiegelt. Es kann festgestellt werden, wann ein Element von einem bestimmten Prozessor erhalten wird, und die Arbeit wird übersprungen, wenn es nicht der Arbeitsdomäne des bestimmten Prozessors entspricht. In einer weiteren Ausführungsform kann zu dem Zeitpunkt, zu dem Operationen in eine Warteschlange gestellt werden, eine Feststellung getroffen werden. Auch können verschiedenste Hardware-Ausführungen verwendet werden, die als Grundlage für die Lokalitätsdomäne einer Speicherregion dienen können. In einer einzelnen Ausführungsform stellt eine Hardware-Ausführungsform einen Test „befindet sich diese Region (oder Position oder Seite usw.) auf dem aktuellen Prozessor?“ bereit. In einer weiteren Ausführungsform kann Hardware eine Instruktion bereitstellen, welche die bestimmte Lokalitätsdomäne einer Region zurückgibt. Ausführungsformen zur Lokalisierung von Garbage-Collection-Threads durch Lenkung eines Garbage-Collection-Service werden hier ebenfalls beschrieben.
  • Wie erwähnt wurde, greift Garbage-Collection auf große Datenmengen zu, um den Speicher auf wiederverwendbaren Speicher hin zu scannen. Als Beispiel kann in einem IBM-System z/Architecture die Latenzzeit für mindestens eine Ebene der Systemarchitektur (d.h. Buchebene) stark uneinheitlich sein, so dass es wünschenswert ist, das Garbage-Collection-Scanning und die Garbage-Collection-Komprimierung auf einem Prozessor durchzuführen, der lokal zu einem Buch gehört. Derzeit gibt es in der System z/Architecture keinen Mechanismus, um Zuordnung von Speicher von dem Speicher eines bestimmten Buches anzufordern, was es schwierig macht, Speicher mit einem bestimmten Buch in Verbindung zu bringen. Folglich werden hierin Verfahren, Systeme und Computerprogrammprodukte offenbart, die die Vorteile eines lokalen Garbage-Collection-Scanning und einer lokalen Garbage-Collection-Komprimierung ermöglichen, welche in einem System vorhanden sind, in dem der Hypervisor und das Betriebssystem keine Schnittstelle zu Anwendungen bereitstellen, um mehrere Blöcke in ausgewählten Lokalitätsdomänen zuzuordnen.
  • Der Mark-and-Sweep-Garbage-Collection-Algorithmus stellt einen Ansatz für Garbage-Collection dar. Bei diesem Algorithmus werden Zeiger untersucht, wobei bei den Programmvariablen begonnen wird, und alle Datensätze, die angetroffen werden, werden markiert. Es erfolgt dann ein Durchlauf durch alle Datensätze in dem Heap und jedwede nicht markierten Datensätze werden freigegeben, und alle markierten Datensätze werden als unmarkiert markiert. Die Annahme bei dem Ansatz ist, dass die Größe eines jeden Datensatzes bekannt ist, die Felder, die Zeiger sind, bekannt sind, und freigegebene Datensätze in einer freien Liste (Freelist) gehalten werden.
  • Nur als ein spezifisches Beispiel ist der Boehm-Demers-Weiser-(BDW-)Mark-and-Sweep-Garbage-Collector aufgrund seiner Portierbarkeit und Sprachunabhängigkeit ein weitverbreiteter Garbage-Collector. Er optimiert eine Klasse von Garbage-Collectors, die als Garbage-Collectors mit mehrdeutigen Wurzeln bezeichnet werden. Solche Garbage-Collectors gibt es, um auf präzise Informationen über Wurzeln und die Kenntnis der Layouts von Objekten zu verzichten, indem angenommen wird, dass ein beliebiger Wert in Wortgröße ein möglicher Verweis auf den Heapspeicher der Anwendung ist. Jeder beliebige Wert, der mehrdeutig auf den Heapspeicher der Anwendung zu verweisen scheint, obwohl dieser vielleicht einfach nur einen Wert hat, der wie ein Verweis auf den Heapspeicher der Anwendung aussieht, wird als Speicherverweis behandelt, und das Objekt, auf das er sich bezieht, wird als „lebendig“ betrachtet, d.h. als nicht für die Garbage Collection in Frage kommend. Das mehrdeutig referenzierte Objekt kann sich nicht bewegen, da seine mehrdeutigen Wurzeln nicht mit einer neuen Adresse des Objekts überschrieben werden können, d.h., wenn der mehrdeutige Wert nicht wirklich ein Speicherverweis ist, sondern lediglich wie ein Speicherverweis aussieht, sollte er dennoch nicht geändert werden. Der BDW-Garbage-Collector behandelt Register, statische Bereiche und Thread-Aktivierungsstacks mehrdeutig. Wenn Objekt-Layout-Informationen vorhanden sind, wie zum Beispiel vom Anwendungsprogrammierer oder Compiler, kann der BDW-Garbage-Collector davon Gebrauch machen, andernfalls jedoch werden in Objekten enthaltene Werte ebenfalls mehrdeutig behandelt.
  • Der Vorteil von Garbage-Collectors mit mehrdeutigen Wurzeln besteht in ihrer Unabhängigkeit von der Anwendungsprogrammiersprache und dem Compiler. Die BDW-Garbage-Collectors unterstützen Garbage-Collection für in C und C++ codierte Anwendungen, die eine genaue Garbage-Collection unmöglich machen, weil sie nicht datentypsicher sind. BDW wird auch oft mit datentypsicheren Sprachen verwendet, deren Compiler nicht die präzisen Informationen bereitstellen, die zur Unterstützung einer genauen Garbage-Collection notwendig sind. Die Mindestanforderung ist, dass das Quellenprogramm keine Speicherverweise aus der Garbage-Collection verbirgt und dass Compiler keine Transformationen durchführen, die Speicherverweise vor der Garbage-Collection verbergen. Somit wird die BDW-Garbage-Collection in diverseren Umgebungen als vielleicht jeder andere Garbage-Collector verwendet. Folglich wurde der BDW-Garbage-Collector stark optimiert, sowohl für die grundlegende Performanz als auch, um die negative Auswirkung von mehrdeutigen Wurzeln zu minimieren.
  • Man beachte, dass der vorstehend erörterte BDW-Mark-and-Sweep-Garbage-Collector mittels eines Beispiels beschrieben wird, das keine Einschränkung darstellt. Verschiedenste Garbage-Collectors, darunter andere Mark-and-Sweep-Collectors, sowie andere Garbage-Collection-Ansätze, wie zum Beispiel auf Kopien basierende Collectors oder Collectors für eine nach Objektalter ablaufende Garbage-Collection, können in Verbindung mit den hierin offenbarten Ausführungsformen in die Praxis umgesetzt werden. Allgemein gesagt, in einem oder mehreren Aspekten hierin wird ein Prozess offenbart, der das Entscheiden, Arbeit lokal durchzuführen, sowie entweder das Zugreifen auf oder das Verwalten von Arbeitseinheiten umfasst, die von einem Collector beispielsweise durch Prozessoraffinität durchgeführt werden sollen.
  • Die grundlegende Struktur der Mark-and-Sweep-Garbage-Collection, wie sie vom BDW-Garbage-Collector ausgeführt wird, besteht in einem Tiefendurchlauf aller erreichbaren Zeiger auf dem Heapspeicher einer Anwendung. Zu diesem Zweck wird ein ursprünglicher Satz von Wurzelzeigern aus der Registerdatei der Anwendung, dem Anwendungsstack, und bekannten Wurzeln in dem Datensegment verwendet, um Speicherverweise in den Heapspeicher der Anwendung zu finden. Dies geschieht, indem ein Markierungsstack mit diesen bekannten Wurzeln initiiert wird.
  • Die Markierungsphase entfernt die Adressen des Heapspeichers der Anwendung aus dem Markierungsstack und verwendet die Speicherverweise in Verbindung mit Informationen über das auf den entdeckten Zeiger gerichtete Objekt, um jedwede in diesem Objekt gespeicherte Zeiger bereitzustellen. Die Mindestmenge an Informationen, die über das Objekt notwendig sind, befindet sich in seiner Startadresse und Länge, die von der Speicherzuordnungsfunktion erhalten werden können. Für solch ein Objekt könnten beliebige korrekt ausgerichtete Datenwörter zulässige Zeiger sein. Jedwede neu entdeckten zulässigen Adressen des Heapspeichers der Anwendung, die auf diese Weise gefunden werden, werden dann auf den Markierungsstack gelegt, und die erreichbaren Objekte werden in einer Markierungsmatrix markiert. Der Algorithmus führt so lange Iterationen durch, bis der Heapspeicher der Anwendung leer ist. Das folgende Codefragment ist ein Beispiel des Markand-Sweep-Algorith mus:
    Figure DE112018005404T5_0001
  • Sobald der Algorithmus alle erreichbaren Objekte des Heapspeichers der Anwendung durchlaufen hat, stellen die Markbits eine Bitmap von allen erreichbaren Objekten dar. Alle nicht markierten Objekte können mit Hilfe eines linearen Sweeps über den Heapspeicher der Anwendung freigegeben werden. Das folgende Codefragment ist ein Beispiel für das Kompilieren mittels Sweep und Freelist von einer einzelnen Ausführungsform eines Mark-and-Sweep-Algorithmus:
    Figure DE112018005404T5_0002
  • Wie erwähnt wurde, kann sich ein rekursiver Ansatz, wie vorstehend mit dem Mark-and-Sweep-Algorithmus kurz skizziert, negativ auf die Performanz auswirken, indem er zu viele Ressourcen benötigt, um die Funktion auszuführen. Ein alternativer Ansatz zu dem vorstehend erörterten allgemeinen Mark-and-Sweep-Algorithmus besteht darin, anstatt eines rekursiven Ansatzes eine Schleife über eine Garbage-Collection-Arbeitswarteschlange auszuführen. Bei Verwendung dieses Ansatzes und lediglich beispielhalber könnte der Markierungsteil des Mark-and-Sweep-Algorithmus wie folgt modifiziert werden:
    Figure DE112018005404T5_0003
  • Die vorstehend erwähnte Verarbeitung wandelt den grundlegenden Mark-and-Sweep-Algorithmus vorteilhaft in einen auf der Aufnahme in eine Warteschlange beruhenden Algorithmus um, wobei Warteschlangen verwaltet werden, um die für eine lokalitätsdomänenbasierte Garbage-Collection-Verarbeitung erwünschte Lokalitätsbeziehung herzustellen, wie hierin offenbart ist.
  • Eine lokalitätsdomänenbasierte Garbage-Collection-Verarbeitung, wie sie hierin offenbart ist, kann auf verschiedensten Systemarchitekturebenen ausgeführt werden. Die 4A bis 4C stellen Beispiele von verschiedenen Systemebenen dar, die diese Konzepte nutzen können. In 4A sind das Buch 0 (B0) sowie das Buch 1 (B1) 102 einer NUMA-Datenverarbeitungsumgebung veranschaulicht, die auch eine Verbindung auf Buch-(oder Ablagefach- oder Ablagebrett-)Ebene enthält, wie vorstehend in Verbindung mit den 1A bis 3 beschrieben wurde. Jedes Buch 102 enthält (in diesem Beispiel) mehrere CPU-Chips 120, von denen jeder über eine Chip-Lokalitätsdomäne verfügt, und mehrere Speicherkanäle 400, von denen jeder andere Lokalitätsmerkmale für Prozessoren auf demselben Chip 120 hat. Wie in 4B dargestellt ist, kann sich ein Anwendungsimage 410 über Prozessoren und Speicher auf Speicherkanälen in mehreren Lokalitätsdomänen über mehrere Hierarchieebenen von Lokalitätsdomänen erstrecken. 4C stellt die Datenverarbeitungsumgebung von 4A dar, wobei gezeigt ist, dass die Systemcontroller-Chips 106 eine weitere Hierarchieebene zu der dargestellten Architektur hinzufügen. In dieser Ausführung sind mehrere Speicherkanäle 400 mit unterschiedlichen Lokalitätsmerkmalen für Prozessoren auf demselben CPU-Chip 120 gezeigt. In der veranschaulichten Architektur gibt es sowohl CPU-Chip-Lokalitätsdomänen als auch Systemchip-Lokalitätsdomänen. Wie erklärt wurde, können einer Anwendung oder einem Anwendungsimage mehrere Prozessoren zugewiesen sein, die sich in verschiedenen CPU-Chips befinden und die verschiedene lokale Speicher oder verschiedene Speicherkanäle haben und sich über verschiedene Bücher (oder Ablagefächer, Ablagebretter usw.) erstrecken können. Das heißt, eine einzelne Anwendung kann Prozessoren nutzen, die auf mehreren Büchern ausgeführt werden.
  • Als weitere Erklärung und wie erwähnt wurde, kann in einer einzelnen Ausführungsform eine einheitliche (oder globale) Arbeitswarteschlange, wie sie beispielsweise in 5A dargestellt ist, mit der affinitisierten Garbage-Collection-Verarbeitung verwendet werden, wie hierin offenbart ist. Eine Ausführung einer einzelnen einheitlichen oder globalen Arbeitswarteschlange kann vorteilhafterweise in bestimmten älteren Systemen verwendet werden, in denen Garbage-Collection-Arbeitswarteschlangen bereitgestellt werden. Eine einzelne Ausführungsform einer Garbage-Collection-Verarbeitung gemäß einem oder mehreren Aspekten, die eine einheitliche oder globale Garbage-Collection-Arbeitswarteschlange verwendet, wie sie beispielsweise in 5A dargestellt ist, könnte (lediglich beispielhalber) einen Algorithmus wie beispielsweise diesen nutzen: 

 while (!empty)
 {

 next_candidate_address = myhead - >address;
 myhead - > processed = TRUE;
 domain = get_domain (next_candidate_address);
 if (domain == mydomain){

  do_gc(next_candidate_address);
  if (myhead == global_queue_head){

 }inc_global_queue head sychronized(); // also skips processed WQ entries 



 myhead++;
}
  • Bei diesem Prozess wird die Lokalitätsdomäne einer in Frage kommenden Adresse (oder Speicherregion) erhalten und dann mit der Lokalitätsdomäne eines aktuellen Prozessors verglichen. Unter der Annahme, dass es eine Übereinstimmung gibt, wird die Garbage-Collection-Verarbeitung diesem Prozessor zugeordnet. Bei Verwendung dieses Ansatzes führen die Prozessoren nur eine Garbage-Collection-Verarbeitung durch, wenn die lokalen Domänen übereinstimmen. In einer weiteren Ausführungsform kann der Garbage-Collection-Worker (d.h. der Prozessor) ein Scanning einer nicht lokalen Garbage-Collection-(GC-)Speicherregion durchführen, wenn für einen Prozessor keine lokalen Einträge in der Arbeitswarteschlange vorhanden sind. Eine beispielhafte Ausführung dieses Prozesses wäre: 
    • 
 while (!empty)
 {

 if (myhead != global_tail) {
 next_candidate_address = myhead - > address;
 domain = get_domain (next_candidate_address);
 if (myhead == global_queue_head) inc_global_queue_head_sychronized ();
 myhead++;
 } else {
 domain=mydomain;
 next_candidate_address = get_global_queue head synchronized();
 }
 if (domain == mydomain)
 do_gc (next_candidate_address);
}
  • Mit diesem Ansatz kann ein Prozessor, sollte ihm lokaler Speicher ausgehen, um darauf eine Garbage-Collection durchzuführen, die Garbage-Collection-Arbeitslast von anderen Prozessoren mit übernehmen, damit die gesamte Garbage-Collection-Arbeit früher fertiggestellt wird.
  • Wie vorstehend erwähnt wurde, können in einer weiteren Ausführung Arbeitswarteschlangen für jede Lokalitätsdomäne auf einer oder mehreren Architekturebenen der Datenverarbeitungsumgebung zugeordnet werden. In dem Beispiel von 5B ist jedem Buch 102 (1A bis 4C) eine Arbeitswarteschlange zugewiesen. Diese Ausführung geht davon aus, dass die Zuordnung stabil genug für eine Aufnahme in die Warteschlange der rechten Domäne ist und dennoch eine korrekte Zuweisung ermöglicht, wenn ein Element aus der Arbeitswarteschlange abgerufen wird. In einer oder mehreren Ausführungsformen kann jede Arbeitswarteschlange, die einer Lokalitätsdomäne entspricht, in dem Speicher zugeordnet werden, der dieser Lokalitätsdomäne entspricht.
  • Eine beliebige Anzahl von Arbeitswarteschlangen kann in Abhängigkeit von der gewünschten Anzahl von Lokalitätsdomänen innerhalb der Architektur genutzt werden. Zum Beispiel könnten Lokalitätsdomänen auf der CPU-Chip-Ebene und/oder auf der SystemChip-Ebene genutzt werden. Bei diesem Ansatz wird die GC-Verarbeitung insofern vereinfacht, als dass der Prozessor nur auf dem Speicher in der zugehörigen (d.h. lokalisierten) Arbeitswarteschlangenstruktur arbeitet. Lediglich als Beispiel wäre eine einzelne Ausführungsform für die Ausführung einer Garbage-Collection-Verarbeitung unter Nutzung eines solchen Ansatzes: 
    • 
 while(!empty(myWQ)){

 next_candidate_address = mq_head- >address;
 do_gc (next_candidate_address);
 mq_head++;
 }
  • Bei dieser Ausführung mit mehreren Arbeitswarteschlangen kann auch eine Lastteilung durch Prozessoren ausgeführt werden, wenn ein Prozessor über keinen lokalen Speicher für das Einsammeln von Garbage verfügt. Ein Beispiel eines solchen Prozesses wäre: 
    • 
 while (!done)
 {

 if (!empty(myWQ){
 next_candidiate_address = mq_head - >address; //exemplary code to obtain next entry
 do_gc (next_candidate_address);
 mq_head++; //exemplary code to remove processed entry
 } else {
 next_candidate_address = work_steal(otherWQ); //exemplary code for „work stealing“ 



 do_gc(next_candidate_address);
}
}
  • Man beachte, dass in einer Umgebung mit mehreren Warteschlangen anfangs eine Entscheidung getroffen werden muss, wo ein Arbeitselement (d.h. eine Speicherregion, die einer Garbage Collection unterzogen werden soll) platziert werden soll. Ein Beispiel dieses Codes kann aufweisen: 
    • 
 enqueue(item_type item)
 {

 domain = get_domain (item);
 switch(domain){
 case0:

  add_to_wq0(item);

 case1:

  add_to_wq1 (item);

 default

  abort(); // example with 2 WQs, other work queue numbers are prog error
 }
  • Es sei auch angemerkt, dass Prozessoren in einer oder mehreren Ausführungsformen affinitäts- oder lokalitätsorientiert sein können und (zum Beispiel) den nächsten Speicherport, der am nächsten liegt, priorisieren, wenn sie keinen zusätzlichen Speicher einer lokalen Domäne zu scannen haben. Ein Beispiel dieser Verarbeitung kann sein: 
    • 
 If (!empty (own_WQ))
  process(own_WQ)
 else if (!empty (nearest_other_WQ))
  process(nearest_other_WQ))
 else if (!empty (next_nearest_other_WQ))
  process(next_nearest_other_WQ))
 else {etc etc.}
  • Gemäß einem oder mehreren weiteren Aspekten wird eine Funktion bereitgestellt, um das Erhalten von Domäneninformationen für Speicher zu vereinfachen und um die Lokalität einer Speichereinheit in Bezug auf eine aktuelle Verarbeitungsdomäne der Datenverarbeitungsumgebung (wie beispielsweise der vorstehend erörterten NUMA-Datenverarbeitungsumgebung) festzustellen, um eine affinitätsdomänenbasierte Garbage-Collection zu vereinfachen.
  • Ein weiteres Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung wird nachstehend unter Bezugnahme auf 6 beschrieben. Unter Bezugnahme auf 6 kann die Datenverarbeitungsumgebung 600 in einem Beispiel wieder auf der z/Architecture beruhen, die von der International Business Machines Corporation, Armonk, NY, angeboten wird. In einem weiteren Beispiel kann die Datenverarbeitungsumgebung auf der von der International Business Machines Corporation, Armonk, NY, USA, angebotenen POWER-Architektur beruhen.
  • Die Datenverarbeitungsumgebung 600 enthält einen zentralen Prozessorkomplex (CPC) 602, der Unterstützung für virtuelle Maschinen bereitstellt. Der CPC 602 ist über eine oder mehrere Steuereinheiten 608 mit einer oder mehreren Eingabe-/Ausgabe-(E/A-)Einheiten 606 verbunden. Der zentrale Prozessorkomplex 602 enthält zum Beispiel einen Prozessorspeicher 604 (der auch als Hauptspeicher bezeichnet wird), der mit einem oder mehreren Zentralprozessoren (die auch als zentrale Verarbeitungseinheiten (CPUs) bezeichnet werden) 610 und einem Eingabe-/Ausgabe-Subsystem 611 verbunden ist, die jeweils nachstehend beschrieben sind.
  • Der Prozessorspeicher 604 enthält zum Beispiel eine oder mehrere virtuelle Maschinen 612, einen VM-Manager wie beispielsweise einen Hypervisor 614, der die virtuellen Maschinen verwaltet, und Prozessorfirmware 615. Ein Beispiel des Hypervisors 614 ist z/VM®, der von der International Business Machines Corporation, Armonk, New York, angeboten wird. Der Hypervisor wird mitunter als Host bezeichnet. Des Weiteren umfasst Firmware in der Verwendung hierin z.B. den Mikrocode und/oder den Millicode des Prozessors. Sie umfasst zum Beispiel die Instruktionen auf Hardware-Ebene und/oder Datenstrukturen, die bei der Ausführung von Maschinencode einer höheren Ebene verwendet werden. In einer einzelnen Ausführungsform umfasst sie zum Beispiel proprietären Code, der üblicherweise als Mikrocode geliefert wird, welcher vertrauenswürdige Software oder Mikrocode, die bzw. der spezifisch für die zugrunde liegende Hardware ist, umfasst und den Betriebssystemzugriff auf die System-Hardware steuert.
  • Die Unterstützung virtueller Maschinen durch den CPC stellt die Möglichkeit bereit, eine große Anzahl an virtuellen Maschinen 612 zu betreiben, von denen jede in der Lage ist, mit verschiedenen Programmen 620 zu arbeiten und ein Gast-Betriebssystem 622 wie beispielsweise Linux auszuführen. Jede virtuelle Maschine 612 ist in der Lage, als ein separates System zu funktionieren. Das heißt, jede virtuelle Maschine kann unabhängig zurückgesetzt werden, ein Gast-Betriebssystem ausführen und mit verschiedenen Programmen arbeiten. Ein Betriebssystem oder ein Anwendungsprogramm, das in einer virtuellen Maschine ausgeführt wird, scheint Zugriff auf ein ganzes und vollständiges System zu haben, doch steht in Wirklichkeit nur ein Teil davon zur Verfügung.
  • Der Prozessorspeicher 604 ist mit den Zentralprozessoren (CPUs) 610 verbunden, bei denen es sich um physische Prozessorressourcen handelt, die virtuellen Maschinen zugewiesen werden können. Zum Beispiel enthält eine virtuelle Maschine 612 einen oder mehrere logische Prozessoren, von denen jeder die gesamte oder einen Teil einer physischen Prozessorressource 610 darstellt, die der virtuellen Maschine dynamisch zugeordnet werden kann. In einer oder mehreren Ausführungsformen kann der Zentralprozessor 610 eine Adressumsetzungseinrichtung 630, wie hierin beschrieben ist, enthalten.
  • Zusätzlich ist jede CPU 610 in einer einzelnen Ausführungsform ein Hardware-Thread, der innerhalb eines Verarbeitungskerns (der auch als Kern bezeichnet wird) 632 ausgeführt wird. Ein Kern enthält einen oder mehrere Threads, und in diesem Beispiel enthält der Kern 632 vier Hardware-Threads. In anderen Beispielen kann die Datenverarbeitungsumgebung einen oder mehrere Kerne enthalten, und jeder Kern kann einen oder mehrere Hardware-Threads enthalten.
  • Wie vorstehend in Verbindung mit den 1A bis 3 erwähnt wurde, kann die Datenverarbeitungsumgebung 600 in einer oder mehreren Ausführungen eine Datenverarbeitungsumgebung oder ein Datenverarbeitungssystem mit nicht einheitlichem Speicherzugriff (NUMA) sein. Wie erklärt wurde, kann der Prozessorspeicher 604 in einer solchen Datenverarbeitungsumgebung zum Beispiel über einen oder mehrere Kerne, Prozessoren oder zentrale Verarbeitungseinheiten wie beispielsweise die zentralen Verarbeitungseinheiten 610 verteilt sein. Des Weiteren, wie vorstehend erklärt wurde, können verschiedene Ebenen von Lokalitätsdomänen innerhalb der NUMA-Datenverarbeitungsumgebung, darunter auch auf der CPU-Ebene, definiert werden. In einer oder mehreren Ausführungen kann der mit einer bestimmten CPU 610 verbundene Prozessorspeicher 604 als ein lokal zu diesem Prozessor gehörender Prozessorspeicher betrachtet werden.
  • Des Weiteren ist der Prozessorspeicher 604 mit einem E/A-Subsystem 611 verbunden. Das Eingabe-/Ausgabe-Subsystem 611 lenkt den Informationsfluss zwischen den Eingabe-/Ausgabe-Steuereinheiten 608 und den Einheiten 606 und dem Hauptspeicher 604. Es ist insofern mit dem zentralen Prozessorkomplex verbunden, als es ein Teil des zentralen Verarbeitungskomplexes oder davon getrennt sein kann.
  • In einem Beispiel kann das Modell der virtuellen Maschinen ein V=V-Modell sein, bei dem der reale oder absolute Speicher einer virtuellen Maschine durch den virtuellen Hostspeicher anstelle des realen oder absoluten Speichers unterstützt werden kann. Jede virtuelle Maschine verfügt über einen zusammenhängenden virtuellen Speicherbereich. Die physischen Ressourcen können vom Host 614 verwaltet werden und die gemeinsam genutzten physischen Ressourcen können den Gast-Betriebssystemen vom Host nach Bedarf zugeteilt werden, um deren Verarbeitungsanforderungen zu erfüllen. Dieses V=V Modell einer virtuellen Maschine (d.h. auslagerbarer Gast) geht davon aus, dass die Interaktionen zwischen den Gast-Betriebssystemen und den physischen gemeinsam genutzten Maschinenressourcen vom Host gesteuert werden, da es die große Anzahl an Gästen dem Host üblicherweise unmöglich macht, die Hardwareressourcen einfach zu partitionieren und sie den konfigurierten Gästen zuzuweisen.
  • In einer einzelnen Ausführungsform interagieren die Hardware/Firmware des Hosts (z.B. z/VM®) und des Prozessors (z.B. System z) in einer kontrollierten kooperativen Weise miteinander, um Operationen des Gast-Betriebssystems zu verarbeiten, ohne die Steuerung von dem/an das Gast-Betriebssystem und von dem/an den Host übertragen zu müssen. Gastoperationen können direkt ohne Hosteingriff über eine Einrichtung ausgeführt werden, die es ermöglicht, dass Instruktionen für den Gast, darunter einen auslagerbaren Speichermodus-Gast, interpretierend ausgeführt werden. Diese Einrichtung stellt eine Instruktion, Start Interpretive Execution (SIE), bereit, die der Host ausgeben kann und die einen als Zustandsbeschreibung bezeichneten Steuerblock angibt, der den Zustand und Steuerungen, wie beispielsweise Ausführungssteuerungen und Modussteuerungen, des Gastes (der virtuellen Maschine) enthält. Die Instruktion versetzt die Maschine in einen Modus für interpretierende Ausführung, in dem Gast-Instruktionen und Unterbrechungen direkt verarbeitet werden, bis eine Bedingung eintritt, die die Aufmerksamkeit des Hosts erfordert. Wenn eine solche Bedingung eintritt, wird die interpretierende Ausführung beendet und es wird entweder eine Host-Unterbrechung übergeben oder die SIE-Instruktion beendet die Speicherung von Einzelheiten der angetroffenen Bedingung; diese letztere Aktion wird als Abfangen bezeichnet.
  • Die hierin beschriebenen Datenverarbeitungsumgebungen unterstützen Architekturfunktionen, wie beispielsweise die dynamische Adressumsetzung (DAT, dynamic address translation). Mit der entsprechenden Unterstützung durch ein Betriebssystem kann die dynamische Adressumsetzungseinrichtung verwendet werden, um einem Benutzer ein System bereitzustellen, in dem der Speicher größer als der in der Konfiguration vorhandene Hauptspeicher erscheint. Dieser scheinbare Hauptspeicher wird als virtueller Speicher bezeichnet und die Adressen, die verwendet werden, um Speicherplätze in dem virtuellen Speicher zu bezeichnen, werden als virtuelle Adressen bezeichnet. Der virtuelle Speicher eines Benutzers kann die Größe des Hauptspeichers bei weitem überschreiten, der in der Konfiguration vorhanden ist und normalerweise im Zusatzspeicher (z.B. Speicher, der nicht direkt adressierbar ist) verwaltet wird. Der virtuelle Speicher wird als aus Blöcken von Adressen bestehend betrachtet, die als Seiten bezeichnet werden. Nur die Seiten des virtuellen Speichers, auf die zuletzt verwiesen wurde, werden zugewiesen, um Blöcke des physischen Hauptspeichers (z.B. des Direktzugriffsspeichers (RAM)) zu belegen. Da der Benutzer auf Seiten des virtuellen Speichers verweist, die nicht im Hauptspeicher erscheinen, werden sie hereingebracht, um Seiten im Hauptspeicher zu ersetzen, die weniger wahrscheinlich benötigt werden. Das Auslagern und Wiedereinlagern von Speicherseiten kann vom Betriebssystem ohne Kenntnis des Benutzers durchgeführt werden.
  • Überdies stellt die Architektur für interpretierende Ausführung in virtuellen Datenverarbeitungsumgebungen einen Speichermodus für absoluten Speicher bereit, der als auslagerbarer Speichermodus bezeichnet wird. Im auslagerbaren Speichermodus erfolgt die Zuordnung von Gast-Hauptspeicher mittels dynamischer Adressumsetzung auf der Hostebene. Der Host hat die Fähigkeit, den realen Speicher von Gästen des auslagerbaren Speichermodus an nutzbare Frames überall im realen Speicher des Hosts zu verstreuen, indem er die Host-DAT verwendet, und Gast-Daten in den Zusatzspeicher auszulagern. Diese Technik bietet Flexibilität bei der Zuordnung von realen Maschinenressourcen, während das erwartete Erscheinen eines zusammenhängenden Bereichs von absolutem Speicher für den Gast erhalten bleibt.
  • Eine Umgebung virtueller Maschinen kann mehrfach die Anwendung von DAT fordern: zuerst auf Gastebene, um eine virtuelle Gastadresse durch von einem Gast verwaltete Umsetzungstabellen in eine nicht virtuelle Gastadresse umzusetzen und dann, für einen auslagerbaren Gast, auf Hostebene, um die entsprechende virtuelle Hostadresse (d.h. die nicht virtuelle Gastadresse) in eine nicht virtuelle Hostadresse, wie beispielsweise eine reale oder absolute Hostadresse, umzusetzen.
  • Eine Abfolge von virtuellen Adressen, die zu virtuellem Speicher gehören, wird als Adressraum bezeichnet, und die dynamische Adressumsetzungseinrichtung kann zur Bereitstellung von mehreren Adressräumen verwendet werden. Diese Adressräume können verwendet werden, um Trennungsgrade zwischen Benutzern bereitzustellen. Eine solche Unterstützung kann einen völlig anderen Adressraum für jeden Benutzer umfassen und auf diese Weise eine vollständige Trennung bereitstellen, oder ein gemeinsam genutzter Bereich kann bereitgestellt werden, indem ein Teil eines jeden Adressraums einem einzelnen gemeinsamen Speicherbereich zugeordnet wird. Auch werden Instruktionen bereitgestellt, die es einem semiprivilegierten Programm erlauben, auf mehr als einen solchen Adressraum zuzugreifen. Die dynamische Adressumsetzung ermöglicht die Umsetzung von, zum Beispiel, virtuellen Adressen aus mehreren unterschiedlichen Adressräumen, ohne dass die Umsetzungsparameter in den Steuerregistern geändert werden müssen.
  • Dynamische Adressumsetzung ist der Prozess, bei dem eine virtuelle Adresse während eines Speicherverweises in die entsprechende reale oder absolute Adresse umgesetzt wird. Dynamische Adressumsetzung kann für Instruktions- und Datenadressen angegeben werden, die von der CPU erzeugt werden. Die reale oder absolute Adresse, die durch die dynamische Adressumsetzung gebildet wird, und die absolute Adresse, die in einer einzelnen Ausführungsform dann durch Voranstellen gebildet wird, haben eine Länge von 64 Bit. Die virtuelle Adresse kann eine primäre virtuelle Adresse, eine sekundäre virtuelle Adresse, eine von einem Zugriffsregister (AR, access register) angegebene virtuelle Adresse oder eine virtuelle Ausgangsadresse sein. Die Adressen werden mittels des primären, des sekundären, eines vom AR angegebenen bzw. des Ausgangsadressraum-Steuerelements (ASCE, address space control element) umgesetzt. Nach Auswahl des entsprechenden Adressraum-Steuerelements ist der Umsetzungsprozess bei allen vier Arten von virtuellen Adressen gleich. Ein Adressraum-Steuerelement kann eine Bezeichnung einer Segmenttabelle oder eine Bezeichnung einer Regiontabelle sein. Die Bezeichnung einer Segmenttabelle oder die Bezeichnung einer Regiontabelle bewirkt, dass eine Umsetzung mittels vom Betriebssystem im realen oder im absoluten Speicher erstellten Tabellen durchgeführt wird.
  • Bei dem Prozess der Umsetzung, wenn eine Bezeichnung einer Segmenttabelle oder eine Bezeichnung einer Regiontabelle verwendet wird, werden drei Arten von Informationseinheiten erkannt - Regionen, Segmente und Seiten. Die virtuelle Adresse wird demgemäß in vier Felder unterteilt. In einem Beispiel werden die Bits 0 bis 32 als Regionsindex (RX, region index) bezeichnet, die Bits 33 bis 43 werden als Segmentindex (SX, segment index) bezeichnet, die Bits 44 bis 51 werden als Seitenindex (PX, page index) bezeichnet, und die Bits 52 bis 63 werden als Byteindex (BX, byte index) bezeichnet. Der RX-Teil einer virtuellen Adresse wird selbst in drei Felder unterteilt. Die Bits 0 bis 10 werden in einer einzelnen Ausführungsform als Regions-Erstindex (RFX) bezeichnet, die Bits 11 bis 21 werden als Regions-Zweitindex (RSX) bezeichnet, und die Bits 22 bis 32 werden als Regions-Drittindex (RTX) bezeichnet.
  • Ein Beispiel einer Umsetzung einer virtuellen Adresse in eine reale Adresse wird unter Bezugnahme auf 7A beschrieben. Dieser Prozess wird hierin als DAT-Durchlauf (oder Seitendurchlauf) bezeichnet, bei dem die Adressumsetzungstabellen durchlaufen werden, um eine Adresse (z.B. eine virtuelle Adresse) in eine andere Adresse (z.B. eine reale Adresse) umzusetzen. In diesem Beispiel enthält ein Adressraum-Steuerelement (ASCE) 700 einen Tabellenursprung 702 sowie eine Bezeichnungstyp-(DT)-Steuerung 704, bei der es sich um eine Angabe einer Startebene für die Umsetzung handelt (d.h. eine Angabe, auf welcher Ebene in der Hierarchie die Adressumsetzung beginnen soll). Unter Verwendung des Tabellenursprungs 702 und des DT 704 wird der Ursprung einer bestimmten Tabelle lokalisiert. Dann werden, basierend auf der Tabelle, Bits der virtuellen Adresse für eine Indexierung in die bestimmte Tabelle verwendet, um den Ursprung der Tabelle der nächsten Ebene zu erhalten. Wenn zum Beispiel die Regions-Ersttabelle (RFT) 706 ausgewählt wird, werden die Bits 0 bis 10 (RFX) 708 der virtuellen Adresse für eine Indexierung in die Regions-Ersttabelle verwendet, um einen Ursprung einer Regions-Zweittabelle (RST) 710 zu erhalten. Dann werden die Bits 11 bis 21 (RSX) 712 der virtuellen Adresse für eine Indexierung in die Regions-Zweittabelle 310 verwendet, um einen Ursprung einer Regions-Dritttabelle (RTT) 714 zu erhalten. Ebenso werden die Bits 22 bis 32 (RTX) 716 der virtuellen Adresse für eine Indexierung in die Regions-Dritttabelle 714 verwendet, um einen Ursprung einer Segmenttabelle 718 zu erhalten. Dann werden die Bits 33 bis 43 (SX) 720 der virtuellen Adresse für eine Indexierung in die Segmenttabelle 718 verwendet, um einen Ursprung der Seitentabelle 722 zu erhalten, und die Bits 44 bis 51 (PX) 724 der virtuellen Adresse werden für eine Indexierung in die Seitentabelle 722 verwendet, um einen Seitentabelleneintrag (PTE, page table entry) 725 zu erhalten, der eine reale Seitenrahmenadresse (PFRA, page frame real address) 726 hat. Die reale Seitenrahmenadresse wird dann mit dem Offset 728 (Bis 52 bis 63) kombiniert (z.B. verknüpft), um eine reale Adresse zu erhalten. Ein Voranstellen kann dann angewendet werden, um die entsprechende absolute Adresse zu erhalten.
  • Ein weiteres Beispiel einer Adressumsetzung ist unter Bezugnahme auf 7B beschrieben. In diesem Beispiel wird ein DAT-Durchlauf durchgeführt, um eine ursprüngliche virtuelle Gastadresse in eine endgültige reale Hostadresse umzusetzen. In diesem Beispiel ist das Adressraum-Steuerelement (ASCE) 700 ein Gastadressraum-Steuerelement und der DT 704 des ASCE 700 gibt an, dass eine durch Gastadressen-Umsetzungsstrukturen 760 festgelegte Gastumsetzung an der Regions-Ersttabelle 706, auf die der Tabellenursprung 702 zeigt, beginnen soll. Folglich werden die entsprechenden Bits der ursprünglichen virtuellen Gastadresse (z.B. RFX 708) für eine Indexierung in die Regions-Ersttabelle 706 verwendet, um einen Zeiger eines Eintrags der Regions-Ersttabelle zu erhalten. Die Adresse des Regions-Ersttabelleneintrags (RFTE, region first table entry) ist eine reale oder absolute Gastadresse. Diese reale oder absolute Gastadresse, mit angewandtem Hauptspeicherursprung und angewandter Hauptspeichergrenze, entspricht einer virtuellen Hostadresse. Diese virtuelle Host-Zwischenadresse wird dann mittels der Hostadressen-Umsetzungsstrukturen 770 umgesetzt. Insbesondere ist das Adressraum-Steuerelement (ASCE) 750 ein Hostadressraum-Steuerelement, das verwendet wird, um eine Startebene für die Umsetzung in den Hostadressen-Umsetzungsstrukturen 772 anzugeben. Basierend auf der Startebene (z.B. der Regions-Ersttabelle), die von dem DT 754 des ASCE 750 angegeben wird, werden die jeweiligen Bits der virtuellen Hostadresse für eine Indexierung in die angegebene Tabelle mit dem Tabellenursprung 752 verwendet, die für eine Umsetzung mittels der Hostadressen-Umsetzungsstruktur 772 verwendet werden soll, wie unter Bezugnahme auf 7A beschrieben ist. Die Umsetzung der virtuellen Hostadresse, die dem Gast-RFTE entspricht, wird fortgesetzt, bis eine reale Host-Seitenrahmenadresse (PFRA, page frame real address) 774a erhalten wird.
  • Bei den Daten an der realen Host-Seitenrahmenzwischenadresse handelt es sich um einen Zeiger auf die nächste Ebene der Gastadressen-Umsetzungsstrukturen (z.B. der Gast-Regions-Zweittabelle 710 in diesem bestimmten Beispiel), und die Umsetzung wird fortgesetzt, wie vorstehend beschrieben wurde. Konkret werden die Hostadressen-Umsetzungsstrukturen 776, 778, 780 und 782 verwendet, um die virtuellen Host-Zwischenadressen, die zu der Gast-Regions-Zweittabelle 710, der Regions-Dritttabelle 714, der Segmenttabelle 718 bzw. der Seitentabelle 722 gehört, umzusetzen, was zu den Host-PFRAs 774b, 774c, 774d bzw. 774e führt. Die reale Host-Seitenrahmenadresse 774e enthält die Adresse eines Gast-Seitentabelleneintrags 725. Der Gast-Seitentabelleneintrag 725 enthält eine reale Gast-Seitenrahmenadresse 726, die mit dem Offset aus der ursprünglichen virtuellen Gastadresse verknüpft ist, um die entsprechende absolute Gastadresse zu erhalten. Der Hauptspeicherursprung und die Hauptspeichergrenze werden dann angewendet, um die entsprechende virtuelle Hostadresse zu berechnen, die dann, wie vorstehend beschrieben wurde, unter Verwendung der Adressumsetzungsstrukturen 784 umgesetzt wird, um die reale Host-Seitenrahmenadresse 774f zu erhalten. Die reale Host-Seitenrahmenadresse wird dann mit dem Offset (z.B. den Bits 52 bis 63) der virtuellen Hostadresse kombiniert (z.B. verknüpft), um die endgültige reale Hostadresse zu erhalten. Damit ist die Umsetzung einer virtuellen Gastadresse in eine reale Hostadresse abgeschlossen.
  • Zwar startet die Umsetzung in den vorstehenden Beispielen an der Regions-Ersttabelle, doch ist dies nur ein Beispiel. Die Umsetzung kann auf jeder Ebene für den Gast oder aber den Host starten.
  • Des Weiteren kann in einer einzelnen Ausführungsform, um die Adressumsetzung zu verbessern, eine Zuordnung der Umsetzung einer virtuellen Adresse in eine reale oder absolute Adresse in einem Eintrag einer zu der Adressumsetzung gehörenden Struktur gespeichert werden, wie beispielsweise einem Adressumsetzpufferspeicher (TLB, translation look-aside buffer). Der TLB ist ein Cachespeicher, der von der Speicherverwaltungshardware verwendet wird, um die Geschwindigkeit der Umsetzung von virtuellen Adressen zu verbessern. Das nächste Mal, wenn eine Umsetzung für eine virtuelle Adresse angefordert wird, wird der TLB geprüft, und wenn sie sich in dem TLB befindet, gibt es einen TLB-Treffer und die reale oder absolute Adresse wird daraus abgerufen. Andernfalls wird ein Seitendurchlauf durchgeführt, wie vorstehend beschrieben wurde.
  • In einem Beispiel, wie in 7C dargestellt, kann ein Adressumsetzpufferspeicher 790 einen oder mehrere Einträge 792 enthalten. Ein Eintrag kann für einen Host oder für einen Gast der Datenverarbeitungsumgebung sein und er kann mit einem Anzeiger oder einem Wert als solcher gekennzeichnet werden. Des Weiteren kann ein DOM-Anzeiger 794 zur Verwendung bereitgestellt werden, wie nachstehend hierin beschrieben ist. (Zum Beispiel kann der DOM-Anzeiger die Lokalitätsdomäne oder alternativ einen Lokalitätsdomänenanzeiger (z.B. Domäne ist lokal, Domäne ist nicht lokal) gemäß einem oder mehreren Aspekten der vorliegenden Erfindung speichern.) Des Weiteren kann ein Eintrag zu einem Seitentabelleneintrag, einem Regiontabelleneintrag oder einem Seitentabelleneintrag der Adressumsetzungstabellen gehören. Viele Ausführungen eines Adressumsetzpufferspeichers sind möglich.
  • Wie angegeben wurde, können Gast-Umsetzungen in dem TLB enthalten sein. Bei diesen Einträgen kann es sich um zusammengesetzte Gast-/Host-Einträge handeln, die implizit eine oder mehrere Host-Umsetzungen enthalten. Zum Beispiel kann ein virtueller Gast-TLB-Eintrag die gesamte Umsetzung von der ursprünglichen virtuellen Gastadresse bis hinab zur endgültigen realen oder absoluten Hostadresse zwischenspeichern. In diesem Fall enthält der Gast-TLB-Eintrag implizit alle Host-Zwischenumsetzungen 772, 776, 778, 780 und 782 sowie die endgültige Host-Umsetzung 784, wie in 7B vorstehend beschrieben wurde. In einem weiteren Beispiel kann ein hierarchischer TLB einen Eintrag in einer ersten Ebene des TLB enthalten, der eine Umsetzung aus der ursprünglichen virtuellen Gastadresse bis hinab zu dem zugehörigen Ursprung der Gast-Seitentabelle 722 zwischenspeichert. Dieser Eintrag der ersten Ebene stellt zum Beispiel einen kombinierten Region- und Segmenttabelleneintrag (CRSTE, combined region and segment table entry) dar und kann als der CRSTE-Teil des TLB bezeichnet werden. Des Weiteren kann der hierarchische TLB einen separaten Eintrag aus einer zweiten Ebene des TLB enthalten, der die Umsetzung aus der Adresse des Gast-Seitentabelleneintrags bis hinab zur endgültigen realen oder absoluten Hostadresse zwischenspeichert. In diesem Beispiel enthalten Gasteinträge in der ersten Ebene des TLB implizit die Host-Zwischenumsetzungen 772, 776, 778 und 780, die den Host-Umsetzungen entsprechen, die Gastbereichs- und Segmenttabellen unterstützen, und Gasteinträge in der zweiten Ebene enthalten implizit die Host-Zwischenumsetzung 782, die die Gastseitentabelle und die endgültige Host-Umsetzung 784 unterstützt, wie in 7B beschrieben ist. Viele Ausführungen eines Adressumsetzpufferspeichers sind möglich.
  • 8 stellt eine einzelne Ausführungsform einer Adressumsetzungseinrichtung 800 dar, die gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet werden kann. Wie veranschaulicht ist, kann die Adressumsetzungseinrichtung 800 einen Eingabemultiplexer 810 enthalten, der Umsetzungsanforderungen multiplext, darunter, zum Beispiel, eine Load-Store-Unit-(LSU-) Suchanforderung an den TLB 801 und eine Datencachespeicher-(DC-) Suchanforderung an den TLB 802 (wobei der Tabellencachespeicher innerhalb des Datencachespeichers ausgeführt ist). Eine ausgewählte TLB- Suchanforderung 803 wird an einen Adressumsetzpufferspeicher (TLB) 820 sowie an eine Umsetzungsengine 830 weitergeleitet. Die TLB-Anforderung initiiert oder startet die Umsetzungsengine 830 nach einem TLB-Fehler basierend auf der TLB-Suchanforderung 803. Man beachte, dass bei Vorliegen eines TLB-Treffers das TLB-Suchergebnis 805 zum Beispiel in einen Tabellencachespeicher 840 geschrieben wird, der sich in dem Datencachespeicher befinden kann. Unter der Annahme, dass ein TLB-Fehler vorliegt, verarbeitet die Umsetzung 830 die Suchanforderung und sendet dabei die Tabellenabrufanforderung 806 möglicherweise an den Tabellencachespeicher 840, der die Abrufergebnisse 807 zurückschickt. Die Umsetzungsengine 830 schreibt das Umsetzungsergebnis 808 in den TLB 820, so dass sich bei der nächsten Auswahl der initiierenden TLB- Suchanforderung das Umsetzungsergebnis im TLB 820 befindet, was zu einem Anforderungs-Treffer führt.
  • Wie anfangs erwähnt wurde, wird es mit zunehmender Asymmetrie und Uneinheitlichkeit des Prozessordesigns immer vorteilhafter, Verarbeitungsaufgaben an einen Prozessor (oder allgemeiner an eine Verarbeitungsdomäne) zu übergeben, der die geringste oder optimale Latenzzeit und die besten Bandbreiteneigenschaften für eine bestimmte Speichereinheit (z.B. Speicherplatz, Adresse, Bereich, Seite usw.) aufweist. Wie vorstehend erwähnt wurde, wird auf reale Speicher in einer NUMA-Datenverarbeitungsumgebung nicht einheitlich durch einen gemeinsam genutzten, einzelnen symmetrischen Schalter zugegriffen, sondern sie sind an bestimmte Verarbeitungsdomänen angeschlossen oder gehören zu diesen, wie beispielsweise zu bestimmten Prozessorkernen, Prozessorchips, Prozessormodulen, Prozessorbüchern und anderen physischen Strukturen. Folglich haben die Elemente, die sich am nächsten an einem Speicher befinden, bessere Zugriffseigenschaften für diesen Speicher.
  • In einem weiteren Aspekt kann das Erkennen von physischen Lokalitätsdomänen und der Performanzaffinität für den Speicher vorteilhaft verwendet werden, wie hierin in Verbindung mit vollständig virtualisierten Systemen und/oder in Verbindung mit Legacy-Software-Stacks beschrieben ist. Innerhalb dieser Kontexte ist es wünschenswert, einen Mechanismus bereitzustellen, um Affinität oder Lokalität einer Speichereinheit zu einer bestimmten Verarbeitungsdomäne zu kennzeichnen.
  • In paravirtualisierten Systemen wie beispielsweise PHYP und der PAPR-Spezifikation, die es ausführt, wird ein Mechanismus bereitgestellt, um an bestimmte Prozessoren oder Prozessorknoten angeschlossen Speicher anzufordern. Bei diesen Systemen muss die Speicherverwaltung jedoch über Aufrufe des Hypervisors anstatt direkt in einem Betriebssystem oder einer Anwendung durchgeführt werden.
  • Damit eine Anwendung in der Lage ist, die Verarbeitung auf einem speichernahen Prozessor zu lokalisieren, ist es, wie hierin erörtert wird, notwendig, die Affinität des Speichers in Bezug auf eine Verarbeitungsfunktion festzustellen, so dass Verarbeitungsaufgaben auf einer Speichereinheit auf der entsprechenden Verarbeitungsdomäne (z.B. dem Prozessor) platziert oder von ihr ausgeführt werden können. Folglich wird gemäß einem oder mehreren hierin offenbarten Aspekten eine Schnittstelle bereitgestellt, um die Affinität oder Lokalität einer Speichereinheit abzufragen, um zum Beispiel die Verarbeitung innerhalb der Datenverarbeitungsumgebung zu vereinfachen, beispielsweise, um einen domänenbasierten Garbage-Collection-Prozess zu vereinfachen.
  • Gemäß einer einzelnen Ausführungsform wird eine Instruktion (load_domain) bereitgestellt, die eine Speichereinheit verwendet und für diesen Speicher physische Lokalitätsdomäneninformationen bereitstellt. In einer einzelnen Ausführungsform kann es sich bei den Domäneninformationen um eine Zahl handeln, die ein oder mehrere lokalitätsbezogene (oder affinitätsbezogene) Attribute des Speichers eindeutig kennzeichnet (z.B. einen zugehörigen Prozessorkern, einen zugehörigen Knoten, ein zugehöriges Buch usw. kennzeichnet). Gemäß einem Aspekt kann die Abfrageantwort die am nächsten gelegene Verarbeitungsdomäne oder -funktion eindeutig kennzeichnen und dazu verwendet werden, die nächstgelegene Verarbeitungsfunktion usw. abzuleiten, indem physische Systeminformationen zum Beispiel entweder durch eine Suche in einer Tabelle, die die Systemstruktur dokumentiert oder enthält, oder durch einen Systemaufruf erhalten werden, der eine solche Tabelle usw. bereitstellt. In einer weiteren Ausführungsform kann ein Zeiger zurückgegeben werden, wobei der Zeiger Informationen wie beispielsweise über Hierarchieebenen und Knoten, denen eine Speicherregion entspricht, oder über Entfernungen zu einem jeden Verarbeitungsdomänenelement innerhalb der Datenverarbeitungsumgebung bereitstellt.
  • Gemäß einem oder mehreren Aspekten kann mindestens ein Systemaufruf und/oder eine Instruktion bereitgestellt werden, um für eine Speichereinheit eine Prozessorkennzeichnung (ID) oder ein Token zu erhalten, die bzw. das eine Locale-Kennung kennzeichnet, der sie entspricht (zum Beispiel eine Locale-Nummer, wie etwa eine Buchnummer, Prozessornummer usw.). In einer weiteren Ausführungsform kann ein Zeiger zurückgegeben werden, wobei der Zeiger Informationen entweder über Hierarchieebenen und Knoten, denen dieser Speicher entspricht, oder über Entfernungen zu einem jedem Verarbeitungselement bereitstellt. In noch einer weiteren Ausführungsform kann eine Instruktion bereitgestellt werden, die eine Speicheradresse und eine Prozessorkennung verwendet und eine Entfernung einer Speicherposition zu einem gekennzeichneten Prozessor zurückgibt. Auf Wunsch kann die Entfernung normalisiert und abstrahiert werden.
  • In einer oder mehreren Ausführungen kann die hierin offenbarte Funktionalität auf vertrauenswürdige Anwendungen, die zum Beispiel signiert, mit einer Satz-ID versehen sind, und/oder Programme beschränkt werden, welche von einem Administrator ausgeführt werden, um zu verhindern, dass Anwendungen Systemdetails entdecken.
  • 9 stellt eine einzelne Ausführungsform einer Datenverarbeitungsumgebung wie beispielsweise der vorstehend beschriebenen NUMA-Datenverarbeitungsumgebung dar, die als eine vereinfachte, beispielhafte Umsetzungsstruktur dargestellt ist, welche die Bücher 102 sowie zum Beispiel eine Konfigurationsmatrix 900, einen oder mehrere Hosts 901 und ein oder mehrere Gastsysteme oder virtuelle Maschinen 902 enthält. In einer oder mehreren Ausführungen könnten die Bücher 102, wie beispielsweise in der vorstehend erörterten z/Architecture-Datenverarbeitungsumgebung, durch eine andere Verarbeitung auf Domänenebene ersetzt werden, wie etwa Chips, an Kerne angeschlossene Speicherports usw. Die Konfigurationsmatrix 900 kann physische Systeminformationen enthalten, die spezifizieren (oder angeben), wo sich zum Beispiel ein bestimmter Speicher innerhalb der Datenverarbeitungsumgebung befindet. Zum Beispiel kann die Konfigurationsmatrix 900 Lokalitätsdomäneninformationen 905 für den physischen Speicher innerhalb des Systems enthalten. Auf diese Informationen kann zum Beispiel über einen oder als Teil von einem Adressumsetzungsprozess gemäß einem oder mehreren hierin offenbarten Aspekten zugegriffen werden. Insbesondere kann, sobald eine reale oder absolute Hostadresse erhalten wurde, diese Adresse verwendet werden, um die Konfigurationsmatrix und insbesondere die Lokalitätsdomäneninformationen innerhalb der Matrix zu referenzieren, um Domäneninformationen für eine bestimmte Speicherregion der Datenverarbeitungsumgebung zu erhalten.
  • 10A stellt eine einzelne Ausführungsform einer load_domain- (oder get domain-)Instruktion gemäß einem oder mehreren Aspekten der vorliegenden Erfindung dar. Wie veranschaulicht ist, kann die load_domain-Instruktion zum Beispiel ein oder mehrere Operationscode-Felder 1000, die einen Opcode enthalten, der eine load_domain-Operation angibt, sowie in dem dargestellten Beispiel einen Adressoperanden 1001, um eine Domäne der angegebenen Adresse als Teil des Adressumsetzungsprozesses festzustellen, sowie ein Zielrückgabe-(target-return-(RT-)Feld 1002 enthalten, das einen Zielrückgabewert für die Domänenladeoperation angibt. Die Verarbeitung der load domain-Instruktion kann zum Beispiel das Feststellen von Lokalitätsdomäneninformationen in Bezug auf die gewünschte Verarbeitungsstrukturebene, wie beispielsweise die Buchebene einer NUMA-Datenverarbeitungsumgebung, für eine(n) gegebene(n) Speicheradresse, Speicherposition, Speicherbereich usw. umfassen, die hierin allgemein als Speichereinheit bezeichnet werden. Die Domäneninformationen können zum Beispiel als eine einzelne Nummer oder als eine Adresse an eine gepackte beschreibende Struktur zurückgegeben werden. Die Verarbeitung kann das Durchlaufen von mehreren Ebenen von Seitentabellen und das Zugreifen auf Informationen, d.h., Domäneninformationen, innerhalb einer Konfigurationsmatrix der Datenverarbeitungsumgebung einschließen. Wie nachstehend erklärt ist, können die Lokalitätsdomäneninformationen dann in einer Datenstruktur wie beispielsweise einem Konfigurationsmatrix-Cachespeicher oder in einem Adressumsetzpufferspeicher zwischengespeichert werden, damit der Verarbeitungsaufwand zum Abrufen der Informationen beim nächsten Mal, wenn die Adresssuche erforderlich ist, verringert werden kann.
  • 10B stellt eine einzelne Ausführungsform einer zu einer load_domain-Instruktion gehörenden Verarbeitung dar. Wie in 10B veranschaulicht ist, kann die Domänenladeverarbeitung 1001 das Durchführen einer Adressumsetzung 1010, um eine reale (oder absolute) Hostadresse zu erhalten, und dann das Verwenden dieser realen Hostadresse zur Durchführung einer Konfigurationsmatrix-Suche 1020 umfassen, um zum Beispiel Domäneninformationen für diese reale Adresse zu erhalten und die Domäneninformationen 1030 zurückzugeben, die dann zum Beispiel in einem Konfigurationsmatrix-Cachespeicher (CAC, config array cache) oder in dem Adressumsetzpufferspeicher (TLB) 1040 zwischengespeichert werden können, was die Domänenladeverarbeitung 1003 abschließt.
  • Man beachte, dass die hierin offenbarte Verarbeitung mehrere Annahmen über die Datenverarbeitungsumgebung trifft. Zum Beispiel wird eine Annahme getroffen, dass der Speicher nicht über Domänen auf Unterseiten-Granularität verteilt ist. Wenn der Speicher jedoch verteilt ist, ist es möglich, das Striping zu lösen, indem das Striping entweder an einer Satzdomäne beginnt und dann einem Muster folgt, oder indem alle Seiten einem gleichen Muster folgen. Diese musterbasierten Stripings könnten von der hierin beschriebenen Verarbeitung somit ebenfalls verarbeitet werden. Des Weiteren wird eine Annahme getroffen, dass jede Seite einen TLB-Umsetzungseintrag in Hardware hat, um erreichbar zu sein.
  • Die Verarbeitungseffizienz innerhalb einer Datenverarbeitungsumgebung kann durch eine effiziente Bereitstellung von Daten verbessert werden. Um nach einer architekturdefinierten Umsetzung auf Lokalitätsdomäneninformationen zuzugreifen, kann eine Suche in einer Konfigurationsmatrix bereitgestellt werden, wie vorstehend beschrieben wurde. Die Verarbeitung kann verbessert werden, indem man die Konfigurationsmatrix zugänglich macht und/oder indem man die Konfigurationsmatrix effizient zugänglich macht. Des Weiteren kann die Effizienz verbessert werden, indem man das Ergebnis einer Lokalitätsdomänensuche in einer Datenstruktur erfasst und eine Möglichkeit bereitstellt, diese Informationen zu suchen oder zu referenzieren. Mehrere Ansätze für eine solche Zwischenspeicherungs-Datenstruktur sind möglich. Zum Beispiel kann ein Betriebssystem oder eine Anwendung über einen zugehörigen Konfigurationsmatrix-Cachespeicher verfügen, auf den in einer oder in mehreren Ausführungsformen eine virtuelle Adresse direkt zugreifen kann, wodurch die Notwendigkeit für die Durchführung einer Adressumsetzung dort vermieden wird, wo die gewünschten Lokalitätsdomäneninformationen zuvor erhalten wurden. In einer oder mehreren Ausführungsformen würde ein solcher Konfigurationsmatrix-Cachespeicher von einer Anwendung verwaltet werden. Man beachte, dass jede beliebige von einer Anwendung verwaltete Speicherstruktur zu diesem Zweck verwendet werden kann. 11 stellt eine einzelne Ausführungsform einer Verarbeitung dar, die beteiligt sein kann. Wie veranschaulicht ist, kann als Teil der Durchführung einer Adressumsetzung, 1100, eine Feststellung getroffen werden, ob die gewünschten Lokalitätsdomäneninformationen lokal in einem Konfigurationsmatrix-Cachespeicher vorhanden sind, 1110. Wenn nicht („nein“), wird eine Suche in der Konfigurationsmatrix durchgeführt, 1120, wobei die relevanten Konfigurationsmatrix-Informationen in den Konfigurationsmatrix-Cachespeicher abgerufen werden, 1130. Nachdem sich die Domäneninformationen jetzt im Konfigurationsmatrix-Cachespeicher befinden, können die Lokalitätsdomäneninformationen zurückgegeben werden, 1140.
  • Wie vorstehend in Verbindung mit 7C veranschaulicht wurde, können die Lokalitätsdomäneninformationen (sobald sie abgerufen wurden) in einer weiteren Ausführungsform zum Beispiel in einem Adressumsetzpufferspeicher zwischengespeichert werden. Eine einzelne Ausführungsform davon ist in 12 dargestellt, wo die gewünschten Lokalitätsdomäneninformationen in Verbindung mit der Durchführung einer Adressumsetzung, 1200, aus dem jeweiligen TLB-Eintrag 1210 (der zum Beispiel als das DOM-Feld in 7C gezeigt ist) erhalten und zurückgegeben werden können, 1220. Man beachte in diesem Zusammenhang, dass die Verwendung einer TLB-Struktur zur Verwaltung von abgerufenen Lokalitätsdomäneninformationen vorteilhaft sein kann, wenn die Domäneninformationen klein sind, beispielsweise nur aus ein paar Bits bestehen. Dieser Ansatz könnte effizienter als ein separater Konfigurationsmatrix-Cachespeicher sein, der zu einem Matrix-Verarbeitungsaufwand führt.
  • Die 13A und 13B stellen beispielhafte Ausführungsformen dar, um die Lokalitätsdomäneninformationen einer bestimmten Speichereinheit innerhalb einer TLB-Struktur bereitzustellen oder zu aktualisieren. In 13A ist ein Speicherzugriffsprozess gezeigt, der zum Beispiel die Durchführung von (einer) Adressumsetzung(en), 1300, wie vorstehend beschrieben wurde, und die Feststellung, ob ein TLB-Treffer vorliegt, 1310, umfasst. Wenn nicht („nein“), kann ein TLB-Durchlauf durchgeführt werden, 1320, wie vorstehend beschrieben wurde. Unter der Annahme, dass ein TLB-Treffer vorliegt, kann dann unter Verwendung von zum Beispiel der Konfigurationsmatrix, 1330, auf den Speicher zugegriffen werden, und Daten und Konfigurationsmatrix-Informationen können an den TLB zurückgesendet werden, 1340. Wenn es für den bestimmten Seitentabelleneintrag noch keine Lokalitätsdomäneninformationen im TLB gibt, 1350, kann der TLB mit den Lokalitätsdomäneninformationen aktualisiert werden, 1360, und die Daten können zurückgegeben werden, 1370.
  • 13B stellt eine einzelne Ausführungsform einer Anforderung für Lokalitätsdomäneninformationen dar, wobei sich die benötigten Informationen derzeit nicht in der TLB-Struktur befinden. Eine Adressumsetzung wird durchgeführt, 1300, eine Abfrage, ob ein TLB-Treffer vorliegt, wird gemacht, 1310. Wenn „ja“, werden die gewünschten Lokalitätsdomäneninformationen zurückgegeben, 1395. Andernfalls erfolgt ein TLB-Durchlauf, 1320, wie vorstehend beschrieben wurde, und die angeforderten Lokalitätsdomäneninformationen werden aus der System-Konfigurationsmatrix erhalten, 1380. Man beachte, dass die Lokalitätsdomäneninformationen auf Wunsch als eine Dummy-Last getarnt werden können. Die TLB-Struktur (wie beispielsweise in 7C gezeigt) wird mit den Lokalitätsdomäneninformationen aktualisiert, 1390, und die Informationen können zurückgegeben werden, 1395.
  • Der Fachmann wird feststellen, dass verschiedene Verbesserungen an der hierin erörterten Verarbeitung zur Anwendung kommen können. Zum Beispiel können eine oder mehrere zusätzliche Helper-Funktionen verwendet werden, um einen Bereich von Lokalitäten, wie beispielsweise einen Speicherbereich, zu kennzeichnen. Ein Start der zugehörigen Lokalitätsdomäne kann erhalten werden, und alle Speicherpositionen, die innerhalb derselben Lokalitätsdomäne liegen, können gekennzeichnet werden. Das heißt, lokale Bereiche des Speichers können zum Beispiel gefunden werden, wenn es gewünscht ist, die zu einem bestimmten Speicherchip gehörenden Speicheradressen zu finden. In einer oder mehreren Ausführungsformen können große Speicherregionen, wie beispielsweise 1-Megabyte- oder 1-Gigabyte-Seiten, gekennzeichnet werden, so dass Lokalitätsdomäneninformationen für eine große Anzahl von Adressen auf einmal erhalten oder angegeben werden könnten. Auf diese Weise könnte die Verarbeitung das Testen der Lokalität für die, zum Beispiel, nächste Million von Speicheradressen vermeiden.
  • 14A stellt eine einzelne Ausführungsform einer is_local_domain-Instruktion gemäß einem oder mehreren Aspekten der vorliegenden Erfindung dar. Wie veranschaulicht ist, kann die is_local_domain-Instruktion zum Beispiel ein oder mehrere Operationscode-Felder 1400, die einen Opcode enthalten, der eine is_local_domain-Operation angibt, sowie zum Beispiel eine Adressposition oder eine Speichereinheit 1402 für einen Prozess, um festzustellen, ob der Speicher lokal ist, sowie einen optionalen Ergebnisanzeiger 1404 enthalten, bei dem es sich um eine Ergebniskennung handeln könnte. In einer oder mehreren Ausführungen könnte die Ergebniskennung angeben, ob eine angegebene Speichereinheit oder Adresse lokal zu einer Verarbeitungsdomäne, wie beispielsweise einem Prozessor gehört, oder nicht lokal ist. Zum Beispiel könnte die is_local_domain-Instruktion in Abhängigkeit davon, ob sich die angegebene Adresse innerhalb der lokalen Domäne auf einem an den lokalen Prozessor angeschlossenen Speicherkanal usw. befindet oder eine Remote-Adresse ist, ein Flag entweder auf „wahr“ (true) oder „falsch“ (false“) setzen. Man beachte, dass es eine Varianz dieser Instruktion geben kann, die entweder als Teil der Instruktion oder als ein Operand eine Lokalitätsebene angeben würde, das heißt, ob der Speicher an den lokalen Prozessor angeschlossen ist oder ob der Speicher an einen der Prozessoren auf demselben lokalen Ablagebrett angeschlossen ist, usw. Des Weiteren könnte die Lokalität bezogen auf eine andere Struktur angegeben werden, wie beispielsweise bezogen auf einen Systemchip, ein Ablagebrett usw. Folglich kann in einer oder mehreren Ausführungen der Grad der Nähe bei der Feststellung berücksichtigt werden, ob lokale Affinität zum Beispiel zu einem Prozessor vorliegt.
  • 14B stellt eine einzelne Ausführungsform der zu einer is_local_domain-Instruktion gehörenden Verarbeitung dar. Wie in 14B veranschaulicht ist, kann die is_local_domain-Verarbeitung 1401 das Erhalten einer Speichereinheit oder Adresse 1410 sowie das Erhalten der Lokalitätsdomäne für, zum Beispiel, einen aktuellen Prozessor 1420 umfassen. Die Verarbeitung stellt fest, ob die Speichereinheit lokal ist 1430. Wenn „ja“, kann der Ergebnisanzeiger so gesetzt werden, dass er Lokalitätsaffinität angibt, 1440, was die is_local_domain-Verarbeitung abschließt, 1445. Andernfalls, wenn die Speichereinheit (oder Adresse) nicht lokal ist, 1430, kann der Ergebnisanzeiger so gesetzt werden, dass er keine Lokalitätsaffinität angibt, 1435, was die Verarbeitung abschließt.
  • Man beachte, dass der Ergebnisanzeiger in einer oder mehreren Ausführungsformen ein Bedingungscode oder ein anderer Anzeiger wie beispielsweise ein Flag sein könnte, um Informationen darüber bereitzustellen, ob die angegebene Speichereinheit lokal ist.
  • In einer oder mehreren Ausführungen kann eine optionale Service-Funktion bereitgestellt werden. Zum Beispiel kann eine domain_range- oder local_domain_range-Instruktion bereitgestellt werden, um eine Größe einer Lokalitätsdomäne bereitzustellen, indem zum Beispiel eine Größe codiert wird, die natürlich ausgerichtet ist und in Verbindung mit einer bereitgestellten Adresse verwendet werden kann. Auch können eine domain_start, domain_end oder local_domain_start, local_domain_end bereitgestellt werden, um die Definition des Beginns bzw. des Endes eines erweiterten angegebenen Speicherbereichs zu vereinfachen. In einer oder mehreren Ausführungsformen kann Lokalität entweder in Bezug auf die kleinste umgebende Größe oder die größte bekannte Ausdehnung, die dieselbe Lokalität hat, definiert werden.
  • Gemäß einem oder mehreren weiteren Aspekten wird eine Funktion bereitgestellt, um Speicherpools zur Verwendung durch Verarbeitungsdomänen wie beispielsweise Hardware-Prozessoren (oder Prozessor-Threads) zu erstellen und zu verwalten, um eine lokalitätsdomänenbasierte Verarbeitung wie die vorstehend beschriebene affinitätsdomänenbasierte Garbage-Collection-Verarbeitung zu vereinfachen. Die Funktion ist insbesondere in einer Datenverarbeitungsumgebung wie der vorstehend erörterten NUMA-Datenverarbeitungsumgebung vorteilhaft.
  • Wie hierin erwähnt, vereinfacht die Durchführung von Operationen auf einem Speicher, der lokal zu einem bestimmten Prozessor gehört, oder allgemeiner eine bestimmte Verarbeitungsdomäne in vorteilhafter Weise die Verarbeitung innerhalb der Datenverarbeitungsumgebung. In vollkommen virtualisierten Umgebungen gibt es möglicherweise jedoch keine Schnittstelle, um zu einer bestimmten Verarbeitungsdomäne gehörenden Speicher anzufordern. Folglich werden hierin Ansätze offenbart, um zu verschiedenen physischen Verarbeitungsdomänen gehörende Speicherpools zu erstellen, so dass man lokale Geschwindigkeits- und Bandbreitenvorteile erhält, selbst wenn der Prozessor (oder die Verarbeitungsdomäne) einen solchen lokalisierten Speicher nicht von einem Supervisor wie beispielsweise dem Betriebssystem oder Hypervisor anfordern kann.
  • Herkömmlicherweise ergibt sich die Speicherzuordnung aus, zum Beispiel, einem einer Anwendung zugewiesenen Heapspeicher, und während der Speicherzuordnung wird die Lokalität des freien Speichers für eine bestimmte Verarbeitungsdomäne nicht berücksichtigt. Der Heapspeicher kann eine Liste mit freiem Speicher sein, der einer beliebigen anfordernden Verarbeitungsdomäne (z.B. einem Prozessor) zugeordnet wird, und der nächste Anforderer (z.B. ein Prozessor) kann zum Beispiel die nächste freie Speicheradresse aus dem Heap erhalten. Dies kann in einer NUMA-Datenverarbeitungsumgebung problematisch sein, in der freier Speicher zu mehreren verschiedenen Lokalitätsdomänen innerhalb der Datenverarbeitungsumgebung gehören kann, und der nächste freie Speicher zu einer Lokalitätsdomäne gehören kann, die fern von dem aktuellen Hardware-Thread (oder Prozessor-Thread) ist, der Speicher anfordert. Dies könnte besonders problematisch in einer Multithread-Anwendung sein, die auf mehreren Prozessoren über mehrere Lokalitätsdomänen hinweg ausgeführt wird.
  • Vorteilhafterweise sind nach Lokalitätsdomäne organisierte Speicherpools oder Freelists hierin offenbart, die es dem Speicher anfordernden Anwendungs-Thread ermöglichen, dass ihm Speicher zugeordnet wird, der lokal zu diesem Thread gehört. Man beachte in diesem Zusammenhang, dass Lokalität auf verschiedenen Ebenen der Datenverarbeitungsumgebung definiert werden kann, wie vorstehend erklärt wurde. Man beachte auch, dass die Lokalitätsdomänen auf einer oder mehreren von mehreren Lokalitätsebenen innerhalb der NUMA-Datenverarbeitungsumgebung definiert werden können, wie beispielsweise lokal auf dem Ablagebrett, lokal auf dem Prozessor, lokal auf dem Thread usw. In einer oder mehreren hierin offenbarten Ausführungen wird eine prozessorlokale Zuordnung lediglich beispielhalber erörtert.
  • Vorteilhafterweise werden hierin in einem oder mehreren Aspekten die Erstellung und Verwendung von lokalitätsdomänenbasierten Speicherpools offenbart, die als lokalitätsdomänenbasierte Freelists bezeichnet werden. In einer oder mehreren Ausführungen wird Speicher für einen Speicherheap erhalten und klassifiziert, indem verschiedene Teile des Speichers entsprechenden lokalitätsdomänenbasierten Freelists zugewiesen werden. Nachdem die Speicherteile nach Lokalitätsdomäne in verschiedene Freelists klassifiziert wurden, kann Speicher dann, wenn er zugeordnet wird, aus der Freelist der Lokalitätsdomäne erhalten werden, die der lokalen Domäne des Anforderers (z.B. des anfordernden Prozessors) entspricht. Wie nachstehend erklärt wird, kann nach der Speicherzuordnung der nächste freie Speicher optional neu ausgewertet werden, um zu bestätigen, dass die Lokalitätsaffinität immer noch vorhanden ist. Wenn sich die Lokalitätsdomäne geändert hat, zum Beispiel aufgrund einer Neuzuweisung der Threads einer Anwendung, die in einer virtualisierten Umgebung ausgeführt wird, kann der neu ausgewertete Speicher einer anderen lokalitätsdomänenbasierten Freelist neu zugeordnet werden. Auch können nach der Komprimierung der Garbage-Collection die Lokalitätsinformationen für den nächsten Speicher, die verarbeitet werden sollen, optional neu ausgewertet werden, um eine fortgesetzte lokalitätsbasierte Affinität sicherzustellen.
  • 15A stellt eine einzelne Ausführungsform einer Speichermanager-Initialisierungsverarbeitung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung dar. (Man beachte, dass die hierin offenbarte Verarbeitung durch einen Prozessor oder eine mit dem Prozessor verbundene Komponente durchgeführt werden kann, der bzw. die für die Zuordnung und Freigabe von Speicher (und möglicherweise Garbage-Collection-Speicher) auf Anforderung einer Anwendung zuständig ist.) Wie veranschaulicht ist, beginnt die Verarbeitung mit einem Speicherbereich, der für einen Heapspeicher der Anwendung angefordert wird, 1502. Der Speicherbereich wird in Speichereinheiten wie beispielsweise Seiten, Objekte, Adressen usw. aufgeteilt und eine nächste nicht verarbeitete Speichereinheit wird erhalten, 1504. Die Lokalitätsdomäne (LD) für die aktuelle Speichereinheit wird erhalten, 1506, wobei zum Beispiel die vorstehend erörterte load_domain-Instruktion verwendet wird. Nachdem die Lokalitätsdomänen 0 bis n (LD0 ... LDn) definiert wurden, stellt die Verarbeitung fest, ob sich die erhaltene Lokalitätsdomäne für die aktuelle Speichereinheit in der Lokalitätsdomäne 0 (LD0) befindet, 1508, und wenn „ja“, fügt sie die Speichereinheit zur Freelist für die Lokalitätsdomäne 0 (LD0) hinzu, 1510. Andernfalls stellt die Verarbeitung fest, ob sich die zu der aktuellen Speichereinheit gehörende Lokalitätsdomäne in der Lokalitätsdomäne 1 (LD1) befindet, 1512, und wenn ja, fügt sie die Speichereinheit zur Freelist für die Lokalitätsdomäne 1 hinzu, 1514. Andernfalls fährt die Verarbeitung bis zur Lokalitätsdomäne n (LDn) fort, 1516, wo die Verarbeitung davon ausgeht, dass die Lokalitätsdomäne mit der Lokalitätsdomäne n übereinstimmt, und fügt die Speichereinheit zur Freelist für die Lokalitätsdomäne n hinzu, 1518. Basierend darauf, dass die aktuelle Speichereinheit zu einer Lokalitätsdomäne hinzugefügt wird, stellt die Verarbeitung fest, ob es weitere nicht verarbeitete Speichereinheiten gibt, 1520, und wenn „ja“, wählt sie die nächste nicht verarbeitete Speichereinheit aus dem Speicherbereich aus. Sobald es keine weiteren nicht verarbeiteten Speichereinheiten gibt, ist diese Initiierungsverarbeitung abgeschlossen,1521.
  • In einer oder mehreren Ausführungen kann ein einzelner großer zusammenhängender Speicherbereich vom Betriebssystem zurückgegeben werden und eine Vielzahl von Unterregionen (das heißt, eine Vielzahl von Speicher-Unterregionen) kann erhalten werden, die verschiedenen Lokalitätsdomänen der Datenverarbeitungsumgebung entsprechen. Eine einzelne Ausführungsform davon ist in 15B dargestellt. Wie veranschaulicht ist, beginnt die Verarbeitung, 1530, mit einem Speicherbereich, der für den Heapspeicher angefordert wird, 1532. Dazu kann das Zurückgegeben einer Adresse mit einem Start des Bereichs gehören, 1534. Eine Instruktion domain_end oder domain_range kann genutzt werden, um die Größe einer Region des zurückgegebenen Bereichs zu erhalten, der sich in der gleichen Lokalitätsdomäne befindet, 1536. Die Lokalitätsdomäne für diese bestimmte Region kann dann gekennzeichnet werden, wobei zum Beispiel die vorstehend erörterte load_domain-Instruktion verwendet wird, 1538. Sobald die Region und die Lokalitätsdomäne erhalten wurden, kann die Verarbeitung feststellen, ob sich die aktuelle Speicherregion in der Lokalitätsdomäne 0 befindet, 1540, und wenn ja, die Region (Adresse, Ende) zur Freelist für die Lokalitätsdomäne 0 hinzufügen, 1542. Andernfalls stellt die Verarbeitung fest, ob sich die gekennzeichnete Region in der Lokalitätsdomäne 1 befindet, 1544, und wenn ja, fügt sie die Region (Adresse, Ende) zur Freelist für die Lokalitätsdomäne 1 hinzu, 1546. Dieser Prozess wird bis zur Lokalitätsdomäne n (LDn) fortgesetzt, 1548, wo die Region (Adresse, Ende) zur Freelist für die Lokalitätsdomäne n hinzugefügt wird, 1550. Sobald die Region zu einer bestimmten Freelist hinzugefügt wurde, wird die Adresse auf das Ende der soeben verarbeiteten Region des Speichers plus 1 erhöht, 1552, und die Verarbeitung stellt fest, ob es weitere nicht verarbeitete Speicherregionen gibt, 1554. Wenn ja, kehrt die Verarbeitung zurück, um die Ausdehnung der nächsten Region festzustellen, indem sie das Ende der nächsten Speicherregion feststellt, 1536. Andernfalls ist die Verarbeitung ausgehend davon, dass kein nicht verarbeiteter Speicher übrig bleibt, abgeschlossen, 1556. Man beachte, dass in einer oder mehreren weiteren Ausführungsformen mehrere große zusammenhängende Bereiche zurückgegeben werden können, wobei zum Beispiel die Verarbeitung von 15B an jedem zurückgegebenen Speicherbereich durchgeführt wird.
  • Anstatt zum Beispiel die Verarbeitung, wie vorstehend in Verbindung mit den 15A und 15B beschrieben, durchzuführen, kann in einer oder mehreren weiteren Ausführungsformen ein Teil dieser Verfahren während der Speicherzuordnung durchgeführt werden, um ausreichend Speicher in einer Freelist zu schaffen, um eine Anforderung, die übergeben wird, zu erfüllen.
  • Als weiteres Beispiel stellt 16 eine einzelne Ausführungsform der Verarbeitung einer Speicherzuordnungsanforderung dar, sobald Speichereinheiten jeweiligen lokalitätsdomänenbasierten Freelists, wie vorstehend beschrieben, zugewiesen wurden. Wie veranschaulicht ist, kann die Speicherzuordnung 1601 das Anfordern einer Speichereinheit (z.B. eines Objekts, einer Seite usw.), 1602, und das Zugreifen auf eine Freelist für die Lokalitätsdomäne des aktuellen Prozessor-Threads, 1604, umfassen. Optional kann die zurückgegebene Speichereinheit ausgewertet werden, um festzustellen, dass sie sich immer noch in der Lokalitätsdomäne des aktuellen Prozessor-Threads befindet, 1606. Zum Beispiel kann die vorstehend beschriebene load_domain-Instruktion für die aus der Freelist erhaltene Speichereinheit genutzt werden, wobei das Ergebnis mit der Lokalitätsdomäne des lokalen Threads verglichen wird. In einer weiteren Ausführungsform kann dies mittels einer is_local domain-Instruktion durchgeführt werden, wie vorstehend beschrieben wurde. Wenn sich die Speichereinheit nicht mehr in der Lokalitätsdomäne des aktuellen Prozessors befindet, kann die Speichereinheit der Freelist einer anderen Lokalitätsdomäne neu zugeordnet werden, der die Speichereinheit derzeit entspricht, 1608. Sobald sie neu zugeordnet wurde, kann die Verarbeitung eine nächste Speichereinheit aus der zugehörigen Freelist des aktuellen Prozessor-Threads erhalten. Sobald eine Speichereinheit in der aktuellen Lokalitätsdomäne erhalten wird, wird das Speicherobjekt dem Aufrufer zugeordnet und der Zeiger auf das zugeordnete Objekt kann an den Aufrufer zurückgegeben werden, 1610, was den Zuordnungsprozess abschließt, 1612. Man beachte, dass gemäß dieser Verarbeitung Speicheranforderungen den Lokalitätsdomänen der Prozesse oder Tasks zugeordnet werden können, die die Zuordnung von Speicher gemäß vorhandenen Speicherzuordnungsschnittstellen anfordern, wodurch Kompatibilität mit vorhandenem Quellcode sichergestellt wird. In einer weiteren Ausführungsform kann eine Lokalitätsdomäne in der Zuordnungsanforderung gemäß einer Zuordnungsschnittstelle der vorliegenden Erfindung angegeben werden, wobei die Speichereinheit(en) aus der/den entsprechenden lokalitätsdomänenbasierten Freelist(s) ausgewählt wird bzw. werden.
  • Gemäß einem oder mehreren weiteren Aspekten kann die Lokalität von Speichereinheiten zum Beispiel während einer Garbage-Collection-Verarbeitung und insbesondere in Verbindung mit einer Speicherkomprimierung durch den Speichermanager neu ausgewertet oder neu festgestellt werden. 17 stellte eine einzelne Ausführungsform einer solchen Neuauswertungsverarbeitung dar. Die Speicherkomprimierung beginnt, 1701, mit der Verlagerung einer Speichereinheit, 1702, und dem Kennzeichnen der Lokalitätsdomäne, in der die Speichereinheit ursprünglich zugeordnet wurde (z.B. der ursprünglichen zugewiesenen lokalitätsdomänenbasierten Freelist), der virtuellen Umgebung, 1704. Eine Zielseite für die Speichereinheit (die einer Seite in der ausgewählten Lokalitätsdomäne entspricht) wird ausgewählt, 1706, und die Verarbeitung stellt fest, ob sich die Zielseite immer noch in dieser Lokalitätsdomäne befindet, 1708. Wenn nicht („nein“), kann die Zielseite einer anderen Lokalitätsdomäne neu zugeordnet werden, das heißt, der Freelist einer anderen Lokalitätsdomäne, zu der die Seite gehört, 1710. Man beachte in diesem Zusammenhang, dass die load_domain-Instruktion für die aus der Freelist erhaltene Speicherregion und für deren Vergleich mit der Lokalitätsdomäne des lokalen Prozessors (oder Threads) verwendet werden kann. In einer weiteren Ausführungsform kann dies mittels der vorstehend erörterten is_local_domain-Instruktion durchgeführt werden. Sobald die Lokalitätsdomäne bestätigt wurde, kann die Speichereinheit in die Zielseite kopiert werden, 1712, was die Verarbeitung für die verlagerte Speichereinheit abschließt, 1714. Man beachte, dass dieser Prozess für jede verlagerte Speichereinheit (z.B. ein Objekt) durchgeführt werden kann.
  • In einer oder mehreren weiteren Ausführungen braucht die Affinität der Speicherregion, als Teil der Speicherkomprimierungsverarbeitung oder in Verbindung damit, nicht unbedingt auf der ursprünglichen lokalitätsbasierten Zuordnung zu beruhen. Vielmehr kann die Lokalitätsaffinität in diesem Kontext zum Beispiel auf wiederholten Zugriffen auf eine Speichereinheit beruhen. Wenn zum Beispiel von einem bestimmten Prozessor in einer bestimmten Lokalitätsdomäne wiederholt auf die Speichereinheit zugegriffen wird, kann es auch dann, wenn die ursprüngliche Zuordnung zu einer anderen Verarbeitungsdomäne erfolgte, wünschenswert sein, die Speichereinheit der bestimmten Verarbeitungsdomäne zuzuordnen, aus der die wiederholten Zugriffe stattfinden. Somit kann die Speichereinheit (Objekt, Pufferspeicher usw.) auf eine Seite verschoben werden, die sich in der Lokalitätsdomäne dieses Prozessors (oder dieser Verarbeitungsdomäne) befindet, der wiederholt auf den Bereich zugreift. Auf diese Weise kann die „Lokalität“ die am meisten erwünschte Lokalitätsaffinität sein, die auf der tatsächlichen Verarbeitung beruht. Anstatt eine Abfrage hinsichtlich der ursprünglichen Lokalitätszuweisung zu machen, kann somit eine Entscheidung darüber getroffen werden, was die beste Lokalität ist, um die Affinität des Speichers zu den verschiedenen Verarbeitungsdomänen für eine bestimmte Anwendung zu optimieren. Man beachte auch, dass, wie vorstehend erwähnt, die Lokalität hierarchisch sein kann und eine Zuweisung von Speicher auf einer beliebigen oder auf mehreren der Hierarchieebenen vorgenommen werden kann. Somit kann eine Speicherkomprimierung in einer einzelnen Ausführungsform Objekte wahlweise in Bezug auf die Buchebene ohne Berücksichtigung der einzelnen Prozessoren platzieren.
  • 18 stellt gemäß einem oder mehreren Aspekten der vorliegenden Erfindung eine einzelne Ausführungsform einer Verarbeitung dar, die in Verbindung mit einer Speicherfreigabe durchgeführt werden kann. Diese Verarbeitung kann für jede(n) freigegebene(n) Speicherteil (oder Entität) wie beispielsweise eine Seite, ein Objekt, ein Adressbereich usw. durchgeführt werden. Eine Speicherfreigabe kann entweder als Reaktion auf eine direkte Speicherfreigabeanforderung (z.B. den Aufruf free() gemäß der POSIX-Standardspezifikation) oder als Reaktion darauf, dass Speicher als Reaktion auf eine Garbage-Collection freigegeben wird, vorgenommen werden. Ein freigegebener Speicherteil wird erhalten, 1800, und eine Lokalitätsdomäne für den aktuellen Speicherteil wird ermittelt, 1802, wobei zum Beispiel die vorstehend erwähnte load_domain-Instruktion verwendet wird. Sobald die Lokalitätsdomäne für den freigegebenen Speicherteil erhalten wird, stellt die Verarbeitung fest, ob sich der Speicher in der Lokalitätsdomäne 0 befindet, 1804, und wenn ja, fügt sie den Speicher zur entsprechenden Domänen-Freelist für die Lokalitätsdomäne 0 hinzu, 1806. Andernfalls stellt die Verarbeitung fest, ob sich der Speicher in der Lokalitätsdomäne 1 befindet, 1808, und wenn ja, fügt sie den Speicher zur Freelist für die Lokalitätsdomäne 1 hinzu, 1810. Dieser Prozess wird bis zur Lokalitätsdomäne n fortgesetzt, wo davon ausgegangen wird, dass sich der Speicher in der Lokalitätsdomäne n befindet, 1812, und der Speicher wird zur Freelist für die Lokalitätsdomäne n hinzugefügt, 1814, was die Verarbeitung 1807 des freigegebenen Speichers abschließt.
  • Ein oder mehrere Aspekte der vorliegenden Erfindung sind untrennbar mit der Computertechnologie verbunden und vereinfachen die Verarbeitung innerhalb eines Computers und verbessern deren Performanz. Weitere Einzelheiten einer einzelnen Ausführungsform zur Vereinfachung der Verarbeitung in einer Datenverarbeitungsumgebung, die sich auf einen oder mehrere Aspekte der vorliegenden Erfindung bezieht, werden unter Bezugnahme auf die 19A bis 19B beschrieben.
  • Die Verarbeitung innerhalb einer Datenverarbeitungsumgebung wird vereinfacht (1900), indem: Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung ermittelt werden (1902) und die Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur zwischengespeichert werden, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu der Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören (1904).
  • In einer oder mehreren Ausführungsformen ist die Speichereinheit eine virtuelle Speichereinheit und das Ermitteln umfasst das Umsetzen der virtuellen Speichereinheit in eine reale Speichereinheit und das Verwenden der realen Speichereinheit, um die Lokalitätsdomäneninformationen aus einer Konfigurationsmatrix abzurufen, die Systemstandortinformationen über physische Komponenten der Datenverarbeitungsumgebung enthält (1906). In einem Beispiel umfasst das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Konfigurationsmatrix-Cachespeicher, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört (1908). In einem weiteren Beispiel umfasst das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Adressumsetzpufferspeicher der Datenverarbeitungsumgebung (1910).
  • Wie in 19B veranschaulicht ist, ist die Datenverarbeitungsumgebung in einer oder mehreren Ausführungsformen eine Datenverarbeitungsumgebung mit nicht einheitlichem Speicherzugriff (NUMA), und die Lokalitätsdomäneninformationen der Speichereinheit zu der Verarbeitungsfunktion umfassen Informationen, die eine bestimmte Domäne der NUMA-Datenverarbeitungsumgebung kennzeichnen, zu der die Speichereinheit eine lokalitätsbasierte Affinität hat (1912).
  • In einer oder mehreren Ausführungen umfasst die Verarbeitung des Weiteren die Feststellung, ob die Speichereinheit Lokalitätsaffinität zu einer Verarbeitungsdomäne einer Vielzahl von Verarbeitungsdomänen der Datenverarbeitungsumgebung hat, wobei die Feststellung das Abrufen der Lokalitätsdomäneninformationen der Speichereinheit aus der Datenstruktur zum Vergleich mit der Lokalität der Verarbeitungsdomäne innerhalb der Datenverarbeitungsumgebung umfasst (1914). In einer oder mehreren Ausführungsformen handelt es sich bei der Datenstruktur um einen Konfigurationsmatrix-Cachespeicher, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört, oder um einen Adressumsetzpufferspeicher der Datenverarbeitungsumgebung (1916). In einem oder mehreren Beispielen umfasst die Verarbeitung des Weiteren das Setzen eines Anzeigers, der eine lokale Affinität angibt, wenn die Lokalitätsdomäneninformationen der Speichereinheit mit der Lokalität der Verarbeitungsdomäne übereinstimmen (1918). Basierend darauf, dass die Speichereinheit Lokalitätsaffinität zu der Verarbeitungsdomäne hat, kann das Verfahren des Weiteren das Durchführen durch die Verarbeitungsdomäne eines Garbage-Collection-Prozesses auf der Speichereinheit umfassen (1920).
  • Viele Variationen sind möglich, ohne vom Wesen von Aspekten der vorliegenden Erfindung abzuweichen.
  • Andere Arten von Datenverarbeitungsumgebungen können auch einen oder mehrere Aspekte der vorliegenden Erfindung enthalten und verwenden, darunter, ohne darauf beschränkt zu sein, Emulationsumgebungen, von denen ein Beispiel unter Bezugnahme auf 20A beschrieben wird. In diesem Beispiel enthält eine Datenverarbeitungsumgebung 20 zum Beispiel eine native zentrale Verarbeitungseinheit (CPU) 22, einen Speicher 24 und eine oder mehrere Eingabe-/Ausgabeeinheiten und/oder Schnittstellen 26, die zum Beispiel über einen oder mehrere Busse 28 und/oder andere Verbindungen miteinander verbunden sind. Als Beispiele kann die Datenverarbeitungsumgebung 20 einen von der International Business Machines Corporation, Armonk, New York, angebotenen PowerPC-Prozessor oder einen pSeries-Server enthalten; und/oder andere Rechner, die auf von der International Business Machines Corporation, Intel oder anderen Unternehmen angebotenen Architekturen beruhen.
  • Die native zentrale Verarbeitungseinheit 22 enthält ein oder mehrere native Register 30 wie beispielsweise ein oder mehrere Mehrzweckregister und/oder ein oder mehrere Spezialregister, die während der Verarbeitung innerhalb der Umgebung verwendet werden. Diese Register enthalten Informationen, die den Zustand der Umgebung zu irgendeinem bestimmten Zeitpunkt darstellen.
  • Überdies führt die native zentrale Verarbeitungseinheit 22 Anweisungen und Code aus, die im Speicher 24 gespeichert sind. In einem bestimmten Beispiel führt die zentrale Verarbeitungseinheit im Speicher 24 gespeicherten Emulator-Code 32 aus. Dieser Code ermöglicht es der in einer Architektur konfigurierten Datenverarbeitungsumgebung, eine andere Architektur zu emulieren. Zum Beispiel ermöglicht der Emulator-Code 32 Rechnern, die auf anderen Architekturen als der z/Architecture beruhen, wie beispielsweise PowerPC-Prozessoren, pSeries-Servern oder anderen Servern oder Prozessoren, die z/Architecture zu emulieren und Software und Instruktionen auszuführen, die beruhend auf der z/Architecture entwickelt wurden.
  • Weitere Einzelheiten in Bezug auf den Emulator-Code 32 werden unter Bezugnahme auf 20B beschrieben. Im Speicher 24 gespeicherte Gast-Instruktionen 40 weisen Software-Instruktionen (die z.B. mit Maschineninstruktionen korrelieren) auf, die für eine Ausführung in einer anderen Architektur als die der nativen CPU 22 entwickelt wurden. Beispielsweise wurden Gast-Instruktionen 40 möglicherweise für eine Ausführung auf einem Prozessor der z/Architecture konzipiert, werden stattdessen aber auf der nativen CPU 22 emuliert, bei der es sich zum Beispiel um einen Intel-Prozessor handeln kann. In einem Beispiel enthält der Emulator-Code 32 eine Instruktionsabrufroutine 42, um eine oder mehrere Gast-Instruktionen 40 aus dem Speicher 24 zu erhalten und um optional eine lokale Pufferung für die erhaltenen Instruktionen bereitzustellen. Er enthält auch eine Instruktionsumsetzungsroutine 44, um die Art der Gast-Instruktion festzustellen, die erhalten wurde, und um die Gast-Instruktion in eine oder mehrere entsprechende native Instruktionen 46 umzusetzen. Diese Umsetzung umfasst zum Beispiel das Kennzeichnen der Funktion, die durch die Gast-Instruktion ausgeführt werden soll, und das Wählen der nativen Instruktion(en) zum Ausführen dieser Funktion.
  • Außerdem enthält der Emulator-Code 32 eine Emulationssteuerungsroutine 48, um zu veranlassen, dass die nativen Anweisungen ausgeführt werden. Die Emulationssteuerungsroutine 48 kann die native CPU 22 veranlassen, eine Routine nativer Instruktionen, die eine oder mehrere zuvor erhaltene Gast-Instruktionen emulieren, auszuführen und am Ende dieser Ausführung die Steuerung an die Instruktionsabrufroutine zurückzugeben, um das Erhalten der nächsten Gast-Instruktion oder einer Gruppe von Gast-Instruktionen zu emulieren. Die Ausführung der nativen Instruktionen 46 kann das Laden von Daten aus dem Speicher 24 in ein Register; das Zurückspeichern von Daten aus einem Register in den Speicher; oder das Durchführen einer bestimmten Art einer arithmetischen oder logischen Operation, die von der Umsetzungsroutine bestimmt wird, umfassen.
  • Jede Routine ist zum Beispiel in Software ausgeführt, die im Speicher gespeichert und von der nativen zentralen Verarbeitungseinheit 22 ausgeführt wird. In weiteren Beispielen sind eine oder mehrere der Routinen oder Operationen in Firmware, Hardware, Software oder einer Kombination daraus ausgeführt. Die Register des emulierten Prozessors können unter Verwendung der Register 30 der nativen CPU oder durch Verwendung von Speicherplätzen im Speicher 24 emuliert werden. In Ausführungsformen können sich die Gast-Instruktionen 40, die nativen Instruktionen 46 und der Emulator-Code 32 in demselben Speicher befinden oder zwischen verschiedenen Speichereinheiten verteilt sein.
  • In der Verwendung hierin umfasst Firmware z.B. den Mikrocode oder den Millicode des Prozessors. Sie umfasst zum Beispiel die Instruktionen auf Hardware-Ebene und/oder Datenstrukturen, die bei der Ausführung von Maschinencode einer höheren Ebene verwendet werden. In einer einzelnen Ausführungsform umfasst sie zum Beispiel proprietären Code, der üblicherweise als Mikrocode geliefert wird, welcher vertrauenswürdige Software oder Mikrocode, die bzw. der spezifisch für die zugrunde liegende Hardware ist, umfasst und den Betriebssystemzugriff auf die System-Hardware steuert.
  • Eine Gast-Instruktion 40, die erhalten, umgesetzt und ausgeführt wird, kann zum Beispiel eine der hierin beschriebenen Instruktionen sein. Die Instruktion, die eine Instruktion von einer Architektur (z.B. der z/Architecture) ist, wird aus dem Speicher abgerufen, umgesetzt und als eine Abfolge von nativen Instruktionen 46 einer anderen Architektur (z.B. PowerPC, pSeries, Intel usw.) dargestellt. Diese nativen Instruktionen werden dann ausgeführt.
  • Ein oder mehrere Aspekte können sich auf das Cloud-Computing beziehen.
  • Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing enthält. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen weiteren Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
  • Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften enthalten, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.
  • Bei den Eigenschaften handelt es sich um die folgenden:
    • On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
    • Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
    • Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
    • Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
    • Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Der Ressourcen-Verbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
  • Die Dienst-Modelle sind wie folgt:
    • Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
    • Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
    • Infrastructure as a Service (IaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
  • Bei den Einsatzmodellen handelt es sich um die folgenden:
    • Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
    • Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann in den eigenen Räumen oder fremden Räumen stehen.
    • Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
    • Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
  • Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten aufweist.
  • Unter Bezugnahme auf 21 ist eine veranschaulichende Cloud-Computing-Umgebung 50 abgebildet. Wie gezeigt ist, weist die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der elektronische Assistent (PDA, personal digital assistant) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Automobil-Computer-System 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder in mehreren Netzwerken wie zum Beispiel privaten, Gemeinschafts-, öffentlichen oder hybriden Clouds, die hier vorstehend beschrieben wurden, oder in einer Kombination daraus zu Gruppen zusammengefasst (nicht gezeigt) werden. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 21 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
  • Unter Bezugnahme auf 22 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (21) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 22 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
  • Eine Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören Mainframe-Computer 61; auf der RISC-(Reduced-Instruction-Set-Computer-)Architektur beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 67 und Datenbank-Software 68.
  • Die Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
  • In einem Beispiel kann die Verwaltungsschicht 80 die nachstehend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen aufweisen. Die Sicherheit stellt die Identitäts-überprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
  • Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und Speicheraffinitäts- und/oder Garbage-Collection-Verarbeitung 96.
  • Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen Integrationsstufe technischer Details handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programminstruktionen gespeichert sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
  • Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
  • Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für eine integrierte Schaltung oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
  • Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
  • Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
  • Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
  • Zusätzlich zu dem Vorstehenden können ein oder mehrere Aspekte von einem Serviceanbieter, der die Verwaltung von Kundenumgebungen anbietet, bereitgestellt, angeboten, eingesetzt, verwaltet, gewartet usw. werden. Zum Beispiel kann der Serviceanbieter Computer-Code und/oder eine Computerinfrastruktur, die einen oder mehrere Aspekte für einen oder mehrere Kunden ausführt, erzeugen, pflegen, unterstützen usw. Der Serviceanbieter kann als Gegenleistung Zahlungen von dem Kunden im Rahmen eines Abonnement- und/oder Gebührenvertrags, als Beispiele, erhalten. Zusätzlich oder alternativ kann der Serviceanbieter Zahlungen aus dem Verkauf von Werbeinhalten an einen oder mehrere Dritte erhalten.
  • In einem Aspekt kann eine Anwendung zur Durchführung von einer oder mehreren Ausführungsformen eingesetzt werden. Als ein Beispiel weist das Einsetzen einer Anwendung das Bereitstellen von Computerinfrastruktur auf, die so beschaffen ist, dass sie eine oder mehrere Ausführungsformen ausführen kann.
  • Als ein weiterer Aspekt kann eine Datenverarbeitungsinfrastruktur eingesetzt werden, die das Integrieren von computerlesbarem Code in ein Datenverarbeitungssystem aufweist, in dem der Code in Verbindung mit dem Datenverarbeitungssystem in der Lage ist, eine oder mehrere Ausführungsformen auszuführen.
  • Als noch ein weiterer Aspekt kann ein Prozess zum Integrieren einer Datenverarbeitungsinfrastruktur bereitgestellt werden, die das Integrieren von computerlesbarem Code in ein Computersystem aufweist. Das Computersystem weist einen durch einen Computer lesbaren Datenträger auf, in dem der Computer-Datenträger eine oder mehrere Ausführungsformen aufweist. Der Code in Verbindung mit dem Computersystem ist in der Lage, eine oder mehrere Ausführungsformen auszuführen.
  • Zwar wurden vorstehend verschiedene Ausführungsformen beschrieben, doch handelt es sich dabei lediglich um Beispiele. Zum Beispiel können Datenverarbeitungsumgebungen anderer Architekturen verwendet werden, um eine oder mehrere Ausführungsformen einzubinden und zu verwenden. Des Weiteren können andere Speicher- und/oder Cache-Hierarchien verwendet werden. Viele Variationen sind möglich.
  • Des Weiteren können andere Arten von Datenverarbeitungsumgebungen profitieren und verwendet werden. Als ein Beispiel kann ein zur Speicherung und/oder Ausführung von Programmcode geeignetes Datenverarbeitungssystem verwendet werden, das mindestens zwei Prozessoren enthält, die über einen Systembus direkt oder indirekt mit Speicherelementen verbunden sind. Zu den Speicherelementen gehört zum Beispiel ein lokaler Speicher, der während der tatsächlichen Ausführung des Programmcodes genutzt wird, ein Massenspeicher und ein Cachespeicher, die eine vorübergehende Speicherung von mindestens einem Teil des Programmcodes ermöglichen, um die Häufigkeit zu verringern, mit der Code während der Ausführung aus dem Massenspeicher abgerufen werden muss.
  • Eingabe-/Ausgabe- bzw. E/A-Einheiten (darunter, ohne darauf beschränkt zu sein, Tastaturen, Bildschirme, Zeigereinheiten, DASD, Band, CDs, DVDs, Thumb-Drives und andere Speichermedien usw.) können entweder direkt oder über dazwischenliegende E/A-Controller mit dem System verbunden sein. Netzadapter können ebenfalls mit dem System verbunden sein, um zu ermöglichen, dass das Datenverarbeitungssystem mit anderen Datenverarbeitungssystemen oder fernen Druckern oder Speichereinheiten über dazwischenliegende private oder öffentliche Netzwerke verbunden werden kann. Modems, Kabelmodems und Ethernet-Karten sind nur einige der verfügbaren Arten von Netzadaptern.
  • Die hierin verwendete Terminologie dient lediglich zur Beschreibung von bestimmten Ausführungsformen und soll nicht einschränkend sein. Die Singular-Formen „ein“, „eine“ und „der“, „die“, „das“ sollen in der Verwendung hierin auch die Pluralformen einschließen, sofern der Kontext nicht eindeutig etwas anderes angibt. Es wird des Weiteren darauf hingewiesen, dass die Begriffe „aufweist“ und/oder „aufweisend“, wenn sie in dieser Spezifikation verwendet werden, das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten bezeichnen, das Vorhandensein oder das Hinzufügen von einem oder mehreren anderen/weiteren Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon jedoch nicht ausschließen.
  • Die entsprechenden Strukturen, Materialien, Vorgänge und Äquivalente von allen Mitteln beziehungsweise Schritt-plus-Funktion-Elementen (step plus function elements) in den nachstehenden Ansprüchen, sofern vorhanden, sollen jedwede Struktur, jedwedes Material oder jedweden Prozess zur Ausführung der Funktion in Kombination mit anderen beanspruchten Elementen, die im Einzelnen beansprucht werden, mit einschließen. Die Beschreibung von einer oder mehreren Ausführungsformen erfolgte zum Zweck der Veranschaulichung und Erläuterung, sie soll aber weder erschöpfend noch auf die offenbarte Form beschränkt sein. Für den Fachmann sind viele Änderungen und Varianten erkennbar. Die Ausführungsform wurde gewählt und beschrieben, um die verschiedenen Aspekte und die praktische Anwendung bestmöglich zu erklären und um anderen Fachleuten das Verständnis verschiedener Ausführungsformen mit verschiedenen Änderungen, wie sie für die jeweilige vorgesehene Verwendung geeignet sind, zu ermöglichen.

    • Claims (20)

    1. Computerprogrammprodukt, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computerprogrammprodukt aufweist: ein durch einen Computer lesbares Speichermedium, das durch eine Verarbeitungsschaltung lesbar ist und Instruktionen zur Durchführung eines Verfahrens speichert, das aufweist: Ermitteln von Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung; und Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu der Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören.
    2. Computerprogrammprodukt nach Anspruch 1, wobei die Speichereinheit eine virtuelle Speichereinheit ist und das Ermitteln das Umsetzen der virtuellen Speichereinheit in eine reale Speichereinheit und das Verwenden der realen Speichereinheit, um die Lokalitätsdomäneninformationen aus einer Konfigurationsmatrix abzurufen, aufweist, welche Systemstandortinformationen über physische Komponenten der Datenverarbeitungsumgebung aufweist.
    3. Computerprogrammprodukt nach Anspruch 1, wobei das Zwischenspeichern ein Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Konfigurationsmatrix-Cachespeicher aufweist, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört.
    4. Computerprogrammprodukt nach Anspruch 1, wobei das Zwischenspeichern ein Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Adressumsetzpufferspeicher der Datenverarbeitungsumgebung aufweist.
    5. Computerprogrammprodukt nach Anspruch 1, wobei es sich bei der Datenverarbeitungsumgebung um eine Datenverarbeitungsumgebung mit nicht einheitlichem Speicherzugriff (NUMA) handelt und die Lokalitätsdomäneninformationen der Speichereinheit zu der Verarbeitungsfunktion Informationen aufweisen, die eine bestimmte Verarbeitungsdomäne der NUMA-Datenverarbeitungsumgebung kennzeichnen, zu der die Speichereinheit eine lokalitätsbasierte Affinität hat.
    6. Computerprogrammprodukt nach Anspruch 1, das des Weiteren die Feststellung aufweist, ob die Speichereinheit Lokalitätsaffinität zu einer Verarbeitungsdomäne einer Vielzahl von Verarbeitungsdomänen der Datenverarbeitungsumgebung hat, wobei die Feststellung ein Abrufen der Lokalitätsdomäneninformationen der Speichereinheit aus der Datenstruktur zum Vergleich mit der Lokalität der Verarbeitungsdomäne innerhalb der Datenverarbeitungsumgebung aufweist.
    7. Computerprogrammprodukt nach Anspruch 6, wobei es sich bei der Datenstruktur um einen Konfigurationsmatrix-Cachespeicher, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört, oder um einen Adressumsetzpufferspeicher der Datenverarbeitungsumgebung handelt.
    8. Computerprogrammprodukt nach Anspruch 6, das des Weiteren das Setzen eines Anzeigers aufweist, der eine lokale Affinität angibt, wenn die Lokalitätsdomäneninformationen der Speichereinheit mit der Lokalität der Verarbeitungsdomäne übereinstimmen.
    9. Computerprogrammprodukt nach Anspruch 6, das des Weiteren basierend darauf, dass die Speichereinheit Lokalitätsaffinität zu der Verarbeitungsdomäne hat, das Durchführen durch die Verarbeitungsdomäne eines Garbage-Collection-Prozesses auf der Speichereinheit aufweist.
    10. Computersystem, um die Verarbeitung innerhalb einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computersystem aufweist: einen Speicher; und einen Prozessor, der mit einem Speicher Daten austauscht, wobei das Computersystem so konfiguriert ist, dass es ein Verfahren durchführt, wobei das Verfahren aufweist: Ermitteln von Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung; und Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu der Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören.
    11. Computersystem nach Anspruch 10, wobei die Speichereinheit eine virtuelle Speichereinheit ist und das Ermitteln ein Umsetzen der virtuellen Speichereinheit in eine reale Speichereinheit und ein Verwenden der realen Speichereinheit, um die Lokalitätsdomäneninformationen aus einer Konfigurationsmatrix abzurufen, aufweist, welche Systemstandortinformationen über physische Komponenten der Datenverarbeitungsumgebung aufweist.
    12. Computersystem nach Anspruch 10, wobei das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Konfigurationsmatrix-Cachespeicher aufweist, der zu einem Betriebssystem oder einer Anwendung der Datenverarbeitungsumgebung gehört.
    13. Computersystem nach Anspruch 10, wobei das Zwischenspeichern das Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einem Adressumsetzpufferspeicher der Datenverarbeitungsumgebung aufweist.
    14. Computersystem nach Anspruch 10, wobei es sich bei der Datenverarbeitungsumgebung um eine Datenverarbeitungsumgebung mit nicht einheitlichem Speicherzugriff (NUMA) handelt und die Lokalitätsdomäneninformationen der Speichereinheit zu der Verarbeitungsfunktion Informationen aufweisen, die eine bestimmte Verarbeitungsdomäne der NUMA-Datenverarbeitungsumgebung kennzeichnen, zu der die Speichereinheit eine lokalitätsbasierte Affinität hat.
    15. Computersystem nach Anspruch 10, das des Weiteren eine Feststellung aufweist, ob die Speichereinheit Lokalitätsaffinität zu einer Verarbeitungsdomäne einer Vielzahl von Verarbeitungsdomänen der Datenverarbeitungsumgebung hat, wobei die Feststellung das Abrufen der Lokalitätsdomäneninformationen der Speichereinheit aus der Datenstruktur zum Vergleich mit der Lokalität der Verarbeitungsdomäne innerhalb der Datenverarbeitungsumgebung umfasst.
    16. Computersystem nach Anspruch 15, das des Weiteren basierend darauf, dass die Speichereinheit Lokalitätsaffinität zu der Verarbeitungsdomäne hat, ein Durchführen durch die Verarbeitungsdomäne eines Garbage-Collection-Prozesses auf der Speichereinheit aufweist.
    17. Durch einen Computer ausgeführtes Verfahren, um die Verarbeitung innerhalb einer Datenverarbeitungsumgebung zu vereinfachen, wobei das durch einen Computer ausgeführte Verfahren aufweist: Ermitteln von Lokalitätsdomäneninformationen einer Speichereinheit zu einer Verarbeitungsfunktion innerhalb der Datenverarbeitungsumgebung; und Zwischenspeichern der Lokalitätsdomäneninformationen der Speichereinheit in einer Datenstruktur, um eine oder mehrere nachfolgende Suchen der Lokalitätsdomäneninformationen zu vereinfachen, die zu einer oder mehreren Auswertungen der Affinität der Speichereinheit zu der Verarbeitungsfunktion der Datenverarbeitungsumgebung gehören.
    18. Durch einen Computer ausgeführtes Verfahren nach Anspruch 17, wobei es sich bei der Datenverarbeitungsumgebung um eine Datenverarbeitungsumgebung mit nicht einheitlichem Speicherzugriff (NUMA) handelt und die Lokalitätsdomäneninformationen der Speichereinheit zu der Verarbeitungsfunktion Informationen aufweisen, die eine bestimmte Verarbeitungsdomäne der NUMA-Datenverarbeitungsumgebung kennzeichnen, zu der die Speichereinheit eine lokalitätsbasierte Affinität hat.
    19. Durch einen Computer ausgeführtes Verfahren nach Anspruch 17, das des Weiteren eine Feststellung aufweist, ob die Speichereinheit Lokalitätsaffinität zu einer Verarbeitungsdomäne einer Vielzahl von Verarbeitungsdomänen der Datenverarbeitungsumgebung hat, wobei die Feststellung das Abrufen der Lokalitätsdomäneninformationen der Speichereinheit aus der Datenstruktur zum Vergleich mit der Lokalität der Verarbeitungsdomäne innerhalb der Datenverarbeitungsumgebung umfasst.
    20. Durch einen Computer ausgeführtes Verfahren nach Anspruch 19, das des Weiteren basierend darauf, dass die Speichereinheit Lokalitätsaffinität zu der Verarbeitungsdomäne hat, ein Durchführen durch die Verarbeitungsdomäne eines Garbage-Collection-Prozesses auf der Speichereinheit aufweist.
    DE112018005404.7T 2017-11-09 2018-10-29 Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers Pending DE112018005404T5 (de)

    Applications Claiming Priority (3)

    Application Number Priority Date Filing Date Title
    US15/807,949 US10445249B2 (en) 2017-11-09 2017-11-09 Facilitating access to memory locality domain information
    US15/807,949 2017-11-09
    PCT/IB2018/058444 WO2019092548A1 (en) 2017-11-09 2018-10-29 Facilitating access to memory locality domain information

    Publications (1)

    Publication Number Publication Date
    DE112018005404T5 true DE112018005404T5 (de) 2020-06-25

    Family

    ID=66328520

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE112018005404.7T Pending DE112018005404T5 (de) 2017-11-09 2018-10-29 Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers

    Country Status (6)

    Country Link
    US (2) US10445249B2 (de)
    JP (1) JP7486419B2 (de)
    CN (1) CN111316248B (de)
    DE (1) DE112018005404T5 (de)
    GB (1) GB2581924B (de)
    WO (1) WO2019092548A1 (de)

    Families Citing this family (8)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US10552309B2 (en) 2017-11-09 2020-02-04 International Business Machines Corporation Locality domain-based memory pools for virtualized computing environment
    US10445249B2 (en) * 2017-11-09 2019-10-15 International Business Machines Corporation Facilitating access to memory locality domain information
    US10997083B2 (en) * 2018-09-04 2021-05-04 Arm Limited Parallel page table entry access when performing address translations
    US11544113B2 (en) * 2019-11-20 2023-01-03 Google Llc Task scheduling for machine-learning workloads
    US11467937B2 (en) * 2020-06-26 2022-10-11 Advanced Micro Devices, Inc. Configuring cache policies for a cache based on combined cache policy testing
    US11687449B2 (en) * 2020-09-10 2023-06-27 International Business Machines Corporation Concurrent marking garbage collection
    KR20220049215A (ko) * 2020-10-14 2022-04-21 삼성전자주식회사 메모리 장치, 호스트 장치 및 이들을 포함하는 메모리 시스템
    US11995342B2 (en) * 2021-12-22 2024-05-28 Micron Technology, Inc. Host initiated garbage collection

    Family Cites Families (41)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    GB2260004B (en) * 1991-09-30 1995-02-08 Apple Computer Memory management unit for a computer system
    US6363410B1 (en) 1994-12-13 2002-03-26 Microsoft Corporation Method and system for threaded resource allocation and reclamation
    US5784697A (en) 1996-03-27 1998-07-21 International Business Machines Corporation Process assignment by nodal affinity in a myultiprocessor system having non-uniform memory access storage architecture
    US6289424B1 (en) 1997-09-19 2001-09-11 Silicon Graphics, Inc. Method, system and computer program product for managing memory in a non-uniform memory access system
    US6546546B1 (en) 1999-05-19 2003-04-08 International Business Machines Corporation Integrating operating systems and run-time systems
    US6865585B1 (en) 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
    US6615322B2 (en) 2001-06-21 2003-09-02 International Business Machines Corporation Two-stage request protocol for accessing remote memory data in a NUMA data processing system
    US7389506B1 (en) 2002-07-30 2008-06-17 Unisys Corporation Selecting processor configuration based on thread usage in a multiprocessor system
    US7185167B2 (en) 2003-06-06 2007-02-27 Microsoft Corporation Heap allocation
    US7380039B2 (en) 2003-12-30 2008-05-27 3Tera, Inc. Apparatus, method and system for aggregrating computing resources
    US7149866B2 (en) 2004-06-04 2006-12-12 International Business Machines Corporation Free item distribution among multiple free lists during garbage collection for more efficient object allocation
    US7290112B2 (en) * 2004-09-30 2007-10-30 International Business Machines Corporation System and method for virtualization of processor resources
    US7383396B2 (en) 2005-05-12 2008-06-03 International Business Machines Corporation Method and apparatus for monitoring processes in a non-uniform memory access (NUMA) computer system
    US7962707B2 (en) 2005-07-06 2011-06-14 Honeywell International Inc. Apparatus and method for deterministic garbage collection of a heap memory
    US7577813B2 (en) 2005-10-11 2009-08-18 Dell Products L.P. System and method for enumerating multi-level processor-memory affinities for non-uniform memory access systems
    US7512745B2 (en) 2006-04-28 2009-03-31 International Business Machines Corporation Method for garbage collection in heterogeneous multiprocessor systems
    JP5233458B2 (ja) 2008-07-15 2013-07-10 株式会社ニコン 画像編集装置及び画像編集プログラム
    US8245008B2 (en) 2009-02-18 2012-08-14 Advanced Micro Devices, Inc. System and method for NUMA-aware heap memory management
    US8312219B2 (en) 2009-03-02 2012-11-13 International Business Machines Corporation Hybrid caching techniques and garbage collection using hybrid caching techniques
    CN102460400B (zh) 2009-06-29 2014-09-24 惠普开发有限公司 基于管理程序的本地和远程虚拟内存页面管理
    US8200718B2 (en) 2009-07-02 2012-06-12 Roberts Michael L Parallelized, incremental garbage collector
    US8943108B2 (en) 2009-12-23 2015-01-27 International Business Machines Corporation Hardware off-load memory garbage collection acceleration
    US8621150B2 (en) 2010-04-09 2013-12-31 International Business Machines Corporation Data placement optimization using data context collected during garbage collection
    US8468289B2 (en) 2010-10-22 2013-06-18 International Business Machines Corporation Dynamic memory affinity reallocation after partition migration
    US8797332B2 (en) 2010-12-15 2014-08-05 Ati Technologies Ulc Device discovery and topology reporting in a combined CPU/GPU architecture system
    US11099982B2 (en) 2011-03-31 2021-08-24 Oracle International Corporation NUMA-aware garbage collection
    US9268595B2 (en) 2011-11-15 2016-02-23 Intel Corporation Scheduling thread execution based on thread affinity
    JP5573829B2 (ja) * 2011-12-20 2014-08-20 富士通株式会社 情報処理装置およびメモリアクセス方法
    US9418003B2 (en) 2012-10-10 2016-08-16 Salesforce.Com, Inc. System, method and computer program product for conditionally performing garbage collection
    US20140115291A1 (en) * 2012-10-19 2014-04-24 Advanced Micro Devices, Inc. Numa optimization for garbage collection of multi-threaded applications
    US10114662B2 (en) 2013-02-26 2018-10-30 Red Hat Israel, Ltd. Updating processor topology information for virtual machines
    US10061622B2 (en) 2013-02-26 2018-08-28 Red Hat Israel, Ltd. Updating memory topology information for virtual machines
    US9342342B2 (en) 2013-03-15 2016-05-17 International Business Machines Corporation Refreshing memory topology in virtual machine operating systems
    JP2016004461A (ja) * 2014-06-18 2016-01-12 富士通株式会社 情報処理装置、入出力制御装置および情報処理装置の制御方法
    US10007525B2 (en) 2014-10-24 2018-06-26 International Business Machines Corporation Freelist based global completion table having both thread-specific and global completion table identifiers
    US10142231B2 (en) 2016-03-31 2018-11-27 Intel Corporation Technologies for network I/O access
    CN106293881B (zh) 2016-08-11 2020-02-07 上海交通大学 一种基于非一致性i/o访问构架的性能监控器及其监控方法
    US10223282B2 (en) 2017-05-23 2019-03-05 International Business Machines Corporation Memory affinity management
    US10552309B2 (en) 2017-11-09 2020-02-04 International Business Machines Corporation Locality domain-based memory pools for virtualized computing environment
    US10445249B2 (en) 2017-11-09 2019-10-15 International Business Machines Corporation Facilitating access to memory locality domain information
    US10691590B2 (en) 2017-11-09 2020-06-23 International Business Machines Corporation Affinity domain-based garbage collection

    Also Published As

    Publication number Publication date
    JP2021502637A (ja) 2021-01-28
    US20190286572A1 (en) 2019-09-19
    CN111316248A (zh) 2020-06-19
    US20190138219A1 (en) 2019-05-09
    WO2019092548A1 (en) 2019-05-16
    GB202007647D0 (en) 2020-07-08
    GB2581924A (en) 2020-09-02
    US11119942B2 (en) 2021-09-14
    US10445249B2 (en) 2019-10-15
    JP7486419B2 (ja) 2024-05-17
    CN111316248B (zh) 2024-04-26
    GB2581924B (en) 2022-05-04

    Similar Documents

    Publication Publication Date Title
    DE112018005404T5 (de) Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers
    DE112015001977B4 (de) Synchronisieren von Aktualisierungen von Statusanzeigern in einer Datenverarbeitungsumgebung
    US11132290B2 (en) Locality domain-based memory pools for virtualized computing environment
    DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
    DE102013017510A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
    DE112017001027B4 (de) Seitenfehlerbehebung
    DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
    DE102014014076A1 (de) Reduzierte Adressenkonvertierung mit mehreren Seitengrößen
    US9817689B2 (en) Dirty page tracking of guest-uncached memory
    DE112019002235T5 (de) Einbinden eines wörterbuch-bearbeitungssystems in ein text mining
    DE112020004181T5 (de) Bereitstellen eines direkten datenzugriffs zwischen beschleunigern und speicher in einer datenverarbeitungsumgebung
    DE102018123669A1 (de) Host-Computer-Anordnung, Remote-Server-Anordnung, Speicherungssystem und Verfahren davon
    DE112018004364B4 (de) Vereinfachung einer verarbeitung in einer datenverarbeitungsumgebung durch gruppierung eines konfigurationsstatusregisters auf grundlage von funktionaler affinität
    DE112018003586T5 (de) Instruktion "inhaltsverzeichnis- (toc) register einrichten"
    US10691590B2 (en) Affinity domain-based garbage collection
    DE112020003929T5 (de) Verwaltung von metadaten von virtuellen speichern
    DE102021131418A1 (de) Dedizierte registerdatei mit begrenzungsinformationen zum schützen vor speicherreferenzen ausserhalb der begrenzungen
    DE112018005758T5 (de) Konfigurationsstatusregister auf arbeitsspeichergrundlage
    DE112017005022T5 (de) Umladen der Bandverarbeitung auf Objektspeicher
    DE112021005233T5 (de) Verbesserte anwendungsleistung durch verwenden vonspeichersystemoptimierung
    DE112018003578T5 (de) Gleichzeitige vorhersage von verzweigungsadressen und aktualisierung des registerinhalts
    DE102012221261A1 (de) Verfahren zum Zwischenspeichern und System zum Ausführen des Verfahrens zum Zwischenspeichern zum Betreiben eines mindestens einen Host-Computer aufweisenden Computerserversystems
    DE112018004636T5 (de) Gleichzeitige änderung einer gemeinsam genutzten cachezeile durch mehrere prozessoren
    DE112020004801T5 (de) Intelligenter datenpool
    DE102016124749B4 (de) Tlb shootdowns für niedrigen overhead

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed
    R079 Amendment of ipc main class

    Free format text: PREVIOUS MAIN CLASS: G06F0013000000

    Ipc: G06F0012102700

    R084 Declaration of willingness to licence