DE102013200030A1

DE102013200030A1 - Hash-basiertes verwalten von speicher-ids

Info

Publication number: DE102013200030A1
Application number: DE102013200030A
Authority: DE
Inventors: Charles E. Mari; Harris M. Morgenstern
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-01-17
Filing date: 2013-01-03
Publication date: 2013-07-18
Anticipated expiration: 2033-01-04
Also published as: GB201300445D0; CN103279427A; GB2500292B; DE102013200030B4; CN103279427B; US20130185536A1; GB2500292A; US8782375B2

Abstract

Das Verwalten von Speicher-IDs in einem Pool wird durch das Bereitstellen eines Hashing-basierten Management-Protokolls in Verbindung mit einem Stack, der Speicher-IDs des Pools enthält, erleichtert. Das Hashing-basierte Management-Protokoll beinhaltet: auf der Grundlage einer Anforderung Holen einer Speicher-ID von dem Stack, ohne einen dem Stack zugeordneten Hash-Link im Hinblick auf eine Aktualisierung zu bewerten, wobei möglicherweise zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und auf der Grundlage der Rückgabe einer freigegebenen Speicher-ID an den Stack Umwandeln der freigegebenen Speicher-ID in einen Hash-Wert und Erkennen, ob in dem Hash-Link, der mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang steht, eine Inkonsistenz vorhanden ist, und auf der Grundlage des Erkennens der Inkonsistenz entweder Aktualisieren des Hash-Links, um die Inkonsistenz zu beseitigen, oder Anzeigen, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde.

Description

HINTERGRUND
Ein oder mehrere Aspekte der vorliegenden Erfindung betreffen allgemein das Verwalten von Zusatzspeicher einer Datenverarbeitungsumgebung und insbesondere das Verwalten von Speicher-IDs von Zusatzspeicher einer Datenverarbeitungsumgebung.
Eine Datenverarbeitungsumgebung kann Hauptspeicher wie auch Zusatzspeicher enthalten, wie beispielsweise Direktzugriffsspeichereinheiten (DASDs). Der Hauptspeicher enthält Speicherseiten, die mithilfe von Realspeicher gesichert und als Realspeicherrahmen bezeichnet werden. Diese Seiten stehen für den Zugriff von Anwendungen, Anweisungen, Operationen oder anderen Entitäten bereit. Der Hauptspeicher ist räumlich begrenzt, und daher werden üblicherweise nur die kürzlich verwendeten Speicherseiten im Hauptspeicher behalten. Andere Speicherseiten werden im Zusatzspeicher behalten.
Zusatzspeicher kann Speicherblöcke enthalten, die gelesen und geschrieben werden. Diese Speicherblöcke werden verwaltet, was die Zuordnung/Freigabe der Blöcke einschließt. Bei einem Beispiel verfolgt das Betriebssystem, welche Blöcke aktuell von welchen Systemkomponenten verwendet werden. Dieses Verfolgen wird durch die Verwendung von Speicher-IDs (bzw. Block-IDs) in Verbindung mit den Speicherblöcken erleichtert.
KURZDARSTELLUNG
Bei einem Aspekt wird hier ein Computerprogrammprodukt zum Verwalten von Speicher-IDs in einem Pool bereitgestellt. Das Computerprogrammprodukt enthält ein Speichermedium, das von einer Verarbeitungsschaltung gelesen werden kann und auf dem Anweisungen zum Ausführen durch die Verarbeitungsschaltung zwecks Ausführens eines Verfahrens gespeichert sind. Das Verfahren beinhaltet beispielsweise das Realisieren eines Hashing-basierten Management-Protokolls in Verbindung mit einem Stack, der Speicher-IDs des Pools enthält, wobei das Hashing-basierte Management-Protokoll aufweist: auf der Grundlage einer Anforderung Holen einer Speicher-ID von dem Stack, ohne einen dem Stack zugeordneten Hash-Link im Hinblick auf eine Aktualisierung zu bewerten, wobei möglicherweise zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und auf der Grundlage der Rückgabe einer freigegebenen Speicher-ID an den Stack Umwandeln der freigegebenen Speicher-ID in einen Hash-Wert (hashing) und Erkennen, ob in dem Hash-Link, der mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang steht, eine Inkonsistenz vorhanden ist, und auf der Grundlage des Erkennens der Inkonsistenz entweder Aktualisieren des Hash-Links, um die Inkonsistenz zu beseitigen, oder Anzeigen, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde.
Verfahren und Systeme im Zusammenhang mit einem oder mehreren Aspekten der vorliegenden Erfindung werden hier ebenfalls beschrieben und beansprucht. Außerdem werden Dienste im Zusammenhang mit einem oder mehreren Aspekten der vorliegenden Erfindung hier ebenfalls beschrieben und möglicherweise beansprucht.
Mithilfe der Techniken der vorliegenden Erfindung werden zusätzliche Merkmale und Vorteile realisiert. Andere Ausführungsformen und Aspekte der Erfindung werden hier ausführlich beschrieben und als ein Teil der beanspruchten Erfindung angesehen.
KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
Ein oder mehrere Aspekte der vorliegenden Erfindung werden besonders aufgezeigt und in den Ansprüchen am Ende der Beschreibung ausdrücklich als Beispiele beansprucht. Das Vorangehende sowie andere Aufgaben, Merkmale und Vorteile der Erfindung sind aus der in Verbindung mit den begleitenden Zeichnungen gelesenen Beschreibung ersichtlich, wobei in den Zeichnungen Folgendes dargestellt ist:
1 zeigt ein Beispiel für eine Datenverarbeitungsumgebung, in der ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und/oder verwendet werden sollen;
2 zeigt eine Ausführungsform der Seitenwechsel-Flusssteuerung in einer Datenverarbeitungsumgebung (wie beispielsweise die in 1 gezeigte) zum Abrufen einer Block-ID, wobei ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und/oder verwendet werden sollen;
3 zeigt eine Ausführungsform der Seitenwechsel-Flussteuerung in einer Datenverarbeitungsumgebung (wie beispielsweise die in 1 gezeigte), wenn eine Anwendung einen Speicherpuffer freigibt, wobei ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und/oder verwendet werden sollen;
4 zeigt eine Ausführungsform von Logik zum Abrufen einer Block-ID aus einem Block-ID-Pool einer Datenverarbeitungsumgebung (wie beispielsweise die in 1 gezeigte), wobei ein Hashing-basiertes Management-Protokoll gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
5A u. 5B zeigen eine Ausführungsform von Logik zum Zurückgeben einer freigegebenen Block-ID an den Block-ID-Pool, wobei ein Hashing-basiertes Management-Protokoll gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6A zeigt eine Ausführungsform von Hashing-basierten Strukturen und beispielhaft das Schieben einer freigegebenen Block-ID auf einen Stack, der Block-IDs eines Pools aufweist, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6B zeigt die Strukturen und das Beispiel aus 6A mit der Rückgabe einer weiteren freigegebenen Block-ID an den Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6C zeigt die Strukturen und das Beispiel aus 6B nach der Rückgabe einer weiteren freigegebenen Block-ID an den Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspektender vorliegenden Erfindung verwendet wird;
6D zeigt die Strukturen und das Beispiel aus 6C nach dem Holen einer Block-ID von dem Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6E zeigt die Strukturen und das Beispiel aus 6D nach der Rückgabe einer freigegebenen Block-ID an den Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6F zeigt die Strukturen und das Beispiel aus 6E nach der Rückgabe einer weiteren freigegebenen Block-ID an den Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6G zeigt die Strukturen und das Beispiel aus 6F nach der Rückgabe einer weiteren freigegebenen Block-ID an den Stack, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
6H zeigt die Strukturen und das Beispiel aus 6G und die Reaktion auf den Versuch, eine doppelt vorhandene freigegebene Block-ID auf den Stack zu schieben, wobei ein Hashing-basiertes Management-Protokoll, wie in 4 bis 5B gezeigt, gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird, und
7 zeigt eine Ausführungsform eines Computerprogrammprodukts, das einen oder mehrerer Aspekte der vorliegenden Erfindung enthalten soll.
AUSFÜHRLICHE BESCHREIBUNG
Wie nachfolgend beschrieben, wird hier eine Verwaltungsfunktion offenbart, die zumindest teilweise ein spezielles Problem betrifft, das mit dem Verwalten von Zusatzspeicher in Zusammenhang steht, nämlich das zweimalige Freigeben desselben Speicherblocks. Dieser Vorgang weist üblicherweise auf ein Datenintegritätsproblem hin, und es ist unbedingt erforderlich, dass ein derartiges Datenintegritätsproblem so schnell wie möglich erkannt wird, damit das Betriebssystem Diagnosedaten sammeln und die zugrunde liegende Ursache des Fehlers ermitteln kann. Es wird hier ein Hashing-basiertes Management-Protokoll bzw. eine Verwaltungsfunktion offenbart, das/die ermöglicht, derartige Fehler auf eine Weise zu erkennen, bei der negative Auswirkungen auf den zugrunde liegenden Speicherverwaltungsansatz minimiert werden.
Eine Ausführungsform einer Datenverarbeitungsumgebung, in der ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und/oder verwendet werden sollen, wird in 1 gezeigt. Die Datenverarbeitungsumgebung 100 kann beispielsweise auf der von der International Business Machines Corporation, Armonk, New York, angebotenen z/Architecture^® beruhen. Die z/Architecture^® wird in einer Veröffentlichung von IBM^® mit dem Titel „z/Architecture Principles of Operation", IBM Publication No. SA22-7832-08, August 2010, beschrieben, die hierin durch Bezugnahme vollständig mit aufgenommen ist. Bei einem Beispiel enthält eine auf der z/Architecture^® beruhende Datenverarbeitungsumgebung das von der International Business Machines Corporation, Armonk, New York, angebotene System zEnterprise 196 (2196). IBM^® und z/Architecture^® sind eingetragene Marken, und zEnterprise 196 und z196 sind Marken der International Business Machines Corporation, Armonk, New York, USA. Andere hier verwendete Namen können eingetragene Marken, Marken oder Produktnamen der International Business Machines Corporation oder anderer Unternehmen sein.
Beispielsweise enthält die Datenverarbeitungsumgebung 100 ein System 102 wie zum Beispiel einen oder mehrere Server, einen zentralen Verarbeitungskomplex usw., das beispielsweise eine oder mehrere Zentraleinheiten (CPUs) 104 enthält, die mithilfe eines oder mehrerer Busse 108 mit dem Hauptspeicher 106 verbunden sind. Eine der Zentraleinheiten 104 kann ein Betriebssystem 120 ausführen wie beispielsweise das von der International Business Machines Corporation angebotene Betriebssystem z/OS^®. Bei anderen Beispielen können eine oder mehrere der Zentraleinheiten andere Betriebssysteme oder kein Betriebssystem ausführen. z/OS^® ist eine eingetragene Marke der International Business Machines Corporation, Armonk, New York, USA.
Die Zentraleinheit(en) 104 und der Hauptspeicher 106 sind außerdem mithilfe einer oder mehrerer Verbindungen 132 (z. B. Busse oder andere Verbindungen) mit einem E-/A-Teilsystem 130 verbunden. Das E-/A-Teilsystem 130 stellt Verbindungen mit einem oder mehreren Zusatzspeichermedien 140 bereit wie beispielsweise einer oder mehreren Direktzugriffsspeichereinheiten (DASDs). Bei einem bestimmten Beispiel für die z/Architecture^® ist das E-/A-Teilsystem ein Kanal-Teilsystem. Das E-/A-Teilsystem kann jedoch auch ein anderes als ein Kanal-Teilsystem sein, und das oder die Zusatzspeichermedien können ein anderes Medium als ein DASD oder zusätzlich zu einem solchen vorhanden sein.
Hauptspeicher und Zusatzspeicher werden bei einem Beispiel von Managern des Betriebssystems 120 verwaltet, darunter beispielsweise ein Realspeichermanager 122 und ein Zusatzspeichermanager 124. Der Realspeichermanager 122 ist verantwortlich für das Verfolgen der Inhalte des Hauptspeichers und das Verwalten der Seitenwechselaktivitäten des Hauptspeichers. Der Zusatzspeichermanager 124 ist verantwortlich für das Verfolgen des Zusatzspeichers und für die Zusammenarbeit mit dem Realspeichermanager, um Speicherorte zum Speichern realer Seiten zu finden, die aus dem Hauptspeicher ausgelagert werden.
Der Zusatzspeichermanager kann verschiedene Arten von Zusatzspeicher verwalten. Bei einer Ausführungsform kann der Zusatzspeicher außerdem in unterschiedlichen Speicherblockgrößen gelesen oder geschrieben werden, darunter beispielsweise 4-K- und 1-M-Speicherblöcke. Das Betriebssystem (z. B. der Zusatzspeichermanager) behält den Überblick darüber, welche Blöcke aktuell von welcher Systemkomponente bzw. welchen Systemkomponenten verwendet werden.
Der Hauptspeicher 106 enthält einen oder mehrere Speicherpools. Bei einer Ausführungsform kann ein Hauptspeicherpool eine Vielzahl von Seitenrahmen einer bestimmten Größe enthalten. Beispielsweise kann der Hauptspeicher 106 eine Vielzahl von Speicherpools enthalten, wie beispielsweise einen 4-K-Speicherpool, die dazu verwendet werden, Anforderungen (z. B. des Betriebssystems und der Anwendungen) von 4-K-Seiten-Speichern zu erfüllen (wobei ein Rahmen der Realspeicher ist, mithilfe dessen die angeforderte Seite gesichert wird); einen 1-M-Speicherpool mit einer festgelegten Seitengröße von 1 M, der zum Erfüllen von Anforderungen von großen Speicherseitenrahmen mit einer festgelegten Größe von 1 M verwendet wird; einen Vierfach-Bereich-Speicherpool, der zum Verwalten von vier aufeinanderfolgenden 4-K-Rahmen im physischen Speicher verwendet wird, oder einen umlagerbaren 1-M-Speicherpool, der zum Bedienen von Anforderungen von umlagerbaren 1-M-Seitenrahmen verwendet wird.
Einem oder mehreren der Realspeicherpools können ein oder mehrere Zusatzspeicherpools zugeordnet sein, wie beispielsweise ein 4-K-Zusatzspeicher-ID-Pool und ein 1-M-Zusatzspeicher-ID-Pool, und jeder von diesen kann sich in einem oder mehreren Stacks 125 befinden oder einen oder mehrere Stacks aufweisen. Gemäß einem oder mehreren Aspekten der vorliegenden Erfindung sind jedem Zusatzspeicher-ID-Stack verschiedene Hashing-basierte Strukturen zugeordnet, darunter ein Hash-Link 127 und ein Hash-Tabellen-Kopfzeilen-Array 129. Wie hier noch näher erläutert wird, weist der Hash-Link 127N Eintragspositionen auf, die den N Eintragspositionen für Speicher-IDs in dem Stack 125 entsprechen. Das Hash-Tabellen-Kopfzeilen-Array ist dem Stack und dem Hash-Link zugeordnet, ist durch Hash-Werte indiziert und enthält Eintragspositionen der Speicher-IDs in dem Stack. Der Hash-Link zeigt an, ob eine oder mehrere Kollisionsketten vorhanden sind, wobei jede Kollisionskette zwei oder mehrere Speicher-IDs in dem Stack verbindet, die in denselben Hash-Wert umgewandelt werden. Der beim Umwandeln der Speicher-ID in einen Hash-Wert verwendete Hash-Wert kann unterschiedlich sein. Beispielsweise ist bei einer Ausführungsform N = 4091, der Stack und der Hash-Link weisen 1 bis 4091 Eintragspositionen auf, und das Hash-Tabellen-Kopfzeilen-Array weist 0 bis 4090 mögliche Einträge in dem Array auf. Bei einem Beispiel teilt der hier offenbarte Hashing-Ansatz die Block-ID durch N (z. B. 4091) und verwendet den Rest als den Hash-Wert, der dazu verwendet wird, zu bestimmen, ob beispielsweise die freigegebene Block-ID in eine Kollisionskette von Block-IDs mit demselben Hash-Wert einbezogen werden sollte.
2 zeigt eine Ausführungsform von Seitenwechsel-Flusssteuerungslogik zum Abrufen einer zusätzlichen Block-ID, wobei ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und/oder verwendet werden sollen. Bei diesem Logikfluss fordert der Realspeichermanager 200, dass ein oder mehrere Rahmen in den Zusatzspeicher 220 umgelagert werden. Bei diesem Vorgang kann der Realspeichermanager ein bestimmtes Zielmedium fordern oder dem Zusatzspeichermanager 210 die Auswahl des Mediums überlassen. Der Zusatzspeichermanager 210 steuert das Übertragen von Daten in den Sicherungs- bzw. Zusatzspeicher 220, beispielsweise an eine oder mehrere Direktzugriffsspeichereinheiten. Wenn der Realspeichermanager Realspeicher in den Zusatzspeicher umlagern muss, fordert der Zusatzspeichermanager zunächst eine oder mehrere Zusatzspeicher-IDs (hier auch als Block-IDs bezeichnet) aus einem Block-ID-Pool 230 an. Wenn der Block-ID-Pool leer ist, fordert der Zusatzspeichermanager die Block-ID(s) von einem Blockmanager an, um die aktuelle Anforderung zu erfüllen und den Block-ID-Pool 240 wieder aufzufüllen. Der Blockmanager verwaltet Zusatzspeicher in beispielsweise 4-K- und 1-M-Blöcken bzw. Speichereinheiten. Jedem Block kann, bei Null beginnend, eine numerische ID zugeordnet sein. Um die Nutzung dieser Blöcke zu verfolgen, verwendet der Blockmanager Mengen von Bitmaps, um anzuzeigen, ob ein bestimmter Block genutzt wird oder freigegeben ist.
3 zeigt Seitenwechsel-Flusssteuerungslogik, wenn von einer Anwendung 300 freigegebener Speicher zurückgegeben wird, wobei ein oder mehrere Aspekte der vorliegenden Erfindung enthalten und/oder verwendet werden sollen. Es sollte beachtet werden, dass die Anwendung Realspeicher freigibt, dass aber aller mit diesem Realspeicher in Zusammenhang stehender Sicherungs- oder Zusatzspeicher ebenfalls freigegeben werden muss. Auf der Grundlage der Freigabe eines Realspeicherpuffers durch die Anwendung gibt der Realspeichermanager den Sicherungs- oder Zusatzspeicher 310 frei, indem er sich mit dem Zusatzspeichermanager 320 in Verbindung setzt, um den entsprechenden Zusatzspeicher 325 freizugeben. Der Zusatzspeichermanager gibt die zugeordnete Block-ID an den Block-ID-Pool 330 oder, wenn in dem Block-ID-Pool nicht ausreichend Speicherplatz für die freigegebene Block-ID vorhanden ist, an den Blockmanager 340 frei.
Die zweimalige Freigabe eines Blocks (oder einer Block-ID) weist darauf hin, dass der Block für zwei verschiedene Zwecke verwendet wurde, und weist daher auf einen Datenintegritätsfehler hin. Diese Arten von Fehlern sollten daher so schnell wie möglich erkannt werden. Mithilfe von Bitvektoren lässt sich dies ohne Weiteres erreichen. Der Realspeichermanager fordert jedoch normalerweise Zusatzspeicher nicht von seiner Blockmanagerkomponente an, sondern wendet sich vielmehr an den Zusatzspeicher-ID-Pool (oder Block-ID-Pool), der separat unterhalten wird, um hinsichtlich der Bereitstellung von Block-IDs die Leistung zu optimieren. Dieser Speicher-ID-Cachespeicher (oder Block-ID-Cachespeicher) dient auf wirkungsvolle Weise als „Front-End” des Blockmanagers. Der Block-ID-Pool enthält bei einer Ausführungsform zwei Stacks von Block-IDs – einen Stack für 4-K-Block-IDs und einen weiteren für 1-M-Block-IDs. Wenn eine Block-ID angefordert wird, wird die Anforderung vom Block-ID-Pool erfüllt, wenn eine Block-ID verfügbar ist. Andernfalls wird der Blockmanager aufgerufen, um zum Wiederauffüllen des geleerten Pools eine Menge von Block-IDs abzurufen. Wenn Block-IDs freigegeben werden, werden sie üblicherweise an den Block-ID-Pool zurückgegeben, sofern der Pool nicht voll ist – in diesem Fall werden sie an den Blockmanager zurückgegeben. Zu ermitteln, ob eine Block-ID, die freigegeben wird, in einem Stack bereits vorhanden ist, kann üblicherweise bei der Suche nach der Block-ID, die im Begriff steht, freigegeben zu werden, das Durchgehen aller Einträge in dem Stack erfordern. Obwohl das Freigeben von Block-IDs unter Leistungsgesichtspunkten von geringerer Bedeutung als das Abrufen von Block-IDs ist, ist es dennoch insoweit von Bedeutung, als ein linearer Scan des Stacks nicht wünschenswert ist.
Es wird daher hier ein alternativer Ansatz offenbart, das heißt ein Hashing-basierter Verwaltungsansatz bzw. ein solches Protokoll, das den oder die zum Seitenwechsel verwendeten Stack(s) von Block-IDs oder Zusatzspeicher-Block-IDs verwaltet, während es gleichzeitig eine Überwachung auf doppelt vorhandene Block-IDs durchführt, was ohne eine wesentliche Beeinträchtigung der Leistung vonstatten geht. Um für den Fall des Abrufens einer Block-ID eine optimale Leistung zu erhalten, Isst das hier offenbarte Hashing-basierte Protokoll eine Inkonsistenz des zugeordneten Hash-Links mit den nach dem Holen einer Speicher-ID vom Stack in dem Stack verbleibenden Speicher-IDs zu. Das heißt, eine Anforderung einer Speicher-ID (oder Block-ID) wird gemäß dem hier beschriebenen Hashing-basierten Management-Protokoll erfüllt, ohne eine Bewertung des dem Stack zugeordneten Hash-Links im Hinblick auf eine Aktualisierung vorzunehmen, wobei eventuell zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird. 4 zeigt eine Ausführungsform dieses Abrufprotokolls.
Wie in 4 gezeigt, beinhaltet das Abrufen einer Block-ID aus einem Block-ID-Pool, auf den der Zusatzspeichermanager zugreift, die Anfrage, ob der Block-ID-Pool leer ist 400, und wenn die Antwort „Ja” lautet, kann keine Block-ID abgerufen werden 410, und der Zusatzspeichermanager fordert die Unterstützung des Blockmanagers an (wie vorstehend erwähnt), um die angeforderte(n) Block-ID(s) abzurufen. Wenn der Block-ID-Pool nicht leer ist, wird der auf die Stackspitze weisende Zeiger (oder Index) verringert 420, und die angeforderte Block-ID wird von dem Stack geholt und an den Dienstaufrufer zurückgegeben, der die Anforderung von Zusatzspeicher aufgerufen hat 430. Bei einer Ausführungsform kann beim Holen einer Block-ID von dem Stack zwecks Rückgabe an den Aufrufer die Kennung der Block-ID in dem Stack verbleiben, und durch Verringern des auf die Stackspitze weisenden Zeigers und anschließendes Schieben einer freigegebenen Block-ID auf den Stack wird die veraltete Block-ID-Kennung des zuvor geholten Blocks einfach überschrieben. Es sollte beachtet werden, dass mit dem Abrufen einer Block-ID aus dem Block-ID-Pool gemäß dem hier offenbarten Management-Protokoll kein mit dem Hash-Verfahren in Zusammenhang stehender Aufwand verbunden ist. Wenn eine oder mehrere freigegebene Block-IDs an den Pool zurückgegeben werden, ermittelt das Hash-Protokoll, ob in dem mit der Rückgabe der freigegebenen Block-ID in Zusammenhang stehenden Hash-Link eine Inkonsistenz vorhanden ist, und aktualisiert auf der Grundlage des Erkennens einer Inkonsistenz entweder den Hash-Link, um die Inkonsistenz zu beseitigen, oder zeigt an, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde. Vorteilhafterweise wird durch diesen Ansatz keine Leistungseinbuße bewirkt, wenn eine Block-ID aus dem Block-ID-Pool abgerufen wird, wobei eventuell zugelassen wird, dass der dem Stack zugeordnete Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und wobei lediglich ein relativ geringer Aufwand bewirkt wird, wenn eine Block-ID zwecks Rückgabe an den Block-ID-Pool freigegeben wird.
Eine Ausführungsform zur Rückgabe einer freigegebenen Block-ID an den Block-ID-Pool mithilfe eines Hashing-basierten Management-Protokolls gemäß einem oder mehreren Aspekten der vorliegenden Erfindung wird in 5A und 5B gezeigt. Es sollte beachtet werden, dass das in 5A und 5B gezeigte Hashing-basierte Management-Protokoll lediglich ein Beispiel für das hier offenbarte Hashing-basierte Management-Protokoll ist.
Wie bereits angemerkt, ist das Push- oder Rückgabeprotokoll aus den 5A und 5B teilweise dafür konfiguriert, die relevanten Teile des Hash-Links zu korrigieren, die möglicherweise durch eine Abruf- oder Abholfunktion inkonsistent wurden. Zu diesem Zweck ruft das Rückgabe- oder Push-Protokoll den Hash-Wert der Block-ID, und sofern vorhanden, eine entsprechende Kollisionskette in dem Hash-Link ab, und beschäftigt sich mit den folgenden Fällen, bevor die Block-ID an der Stackspitze hinzugefügt wird. Genauer gesagt, schreitet das Protokoll fort bis: (1) Der entsprechende Hash-Tabellen-Eintrag enthält eine „Null”, was bedeutet, dass keine Hash-Kollision zwischen der hinzuzufügenden Block-ID und irgendwelchen anderen Block-IDs vorliegt und die Block-ID daher an der Stackspitze hinzugefügt werden kann; (2) die Hash-Tabelle oder die Kollisionskette in dem Hash-Link zeigen auf einen Eintrag oberhalb der Stackspitze, wobei in diesem Fall die Block-ID an der Stackspitze hinzugefügt werden kann und alle veralteten Einträge so abgeändert werden können, dass sie auf die neue Stackspitze zeigen; (3) der Hash-Link zeigt auf einen Eintrag, der sich nicht in der aktuellen Hash-Kette befindet (sondern unterhalb der Stackspitze), und in diesem Fall wird der vorherige Hash-Link so angepasst, dass er auf den Eintrag zeigt, der gerade hinzugefügt werden soll (d. h. an der Stackspitze), und die freigegebene Block-ID wird der Stackspitze hinzugefügt; (4) ein Eintrag in einer Kollisionskette in dem Hash-Link weist eine Block-ID auf, die mit der Block-ID, die gerade hinzugefügt werden soll, identisch ist. In diesem Fall liegt ein Fehler oder eine Verdoppelung vor, und der Prozess wird abgebrochen; (5) andernfalls, bei Vorliegen einer Hash-Kollision, wird der Prozess mit dem nächsten Eintrag in der Kollisionskette in dem Hash-Link wiederholt. Dieses Protokoll wird nachfolgend mit Bezug auf die Logik aus den 5A und 5B näher erläutert.
Wie in 5A gezeigt, beinhaltet das Verwalten der Rückgabe einer freigegebenen Block-ID an den Block-ID-Pool das Ermitteln, ob der Block-ID-Pool voll ist 500, und wenn die Antwort „Ja” lautet, wird dem Aufrufer (oder dem Zusatzspeichermanager) signalisiert, dass der Block-ID-Pool voll ist 502, und in diesem Fall wird die Block-ID wie vorstehend beschrieben an den Blockmanager zurückgegeben. Unter der Voraussetzung, dass der Block-ID-Pool nicht voll ist, wird die Block-ID mithilfe eines Hash-Verfahrens umgewandelt, um einen Hash-Wert zu erhalten 504. Bei einem Beispiel erhält man den Hash-Wert durch Teilen der Block-ID durch eine Zahl N, die gleich der Anzahl der Eintragspositionen in dem Stack oder Hash-Link (wie vorstehend beschrieben) ist. Bei einem konkreten Beispiel kann diese Zahl 4091 sein, und das Hash-Tabellen-Kopfzeilen-Array enthält die Eintragspositionen 0 bis 4090, die den möglichen Resten entsprechen, die sich beim Teilen der Block-ID durch 4091 ergeben, wie in den nachfolgend mit Bezug auf die 6A bis 6H angeführten Beispielen näher erläutert wird.
Die Verarbeitung ermittelt dann, ob das Hash-Tabellen-Kopfzeilen-Array für den erhaltenen Hash-Wert aktuell Null (bzw. leer) ist 506. Wenn dies zutrifft, wird die Block-ID auf die Stackspitze geschoben 508, das Hash-Tabellen-Kopfzeilen-Array mit der Eintragsposition für die Stackspitze aktualisiert, der dieser Eintragsposition entsprechende Hash-Link auf Null gesetzt und der auf die Stackspitze weisende Zeiger auf den nächsten Eintrag erhöht 510. Es sollte beachtet werden, dass das Hash-Tabellen-Kopfzeilen-Array bei diesem Beispiel die Eintragsposition der Block-ID in dem Stack angibt. Vorteilhafterweise wird in den meisten Fällen, in denen eine freigegebene Block-ID zurückgegeben wird, dieser Prozessablauf durch die Logik befolgt.
Wenn das Hash-Tabellen-Kopfzeilen-Array für den erhaltenen Wert ungleich Null ist 506, ermittelt die Verarbeitung, ob der entsprechende Eintrag in der Hash-Tabelle größer oder gleich dem auf die Stackspitze weisenden Zeiger ist 512, und wenn die Antwort „Ja” lautet, ist der Wert in dem Hash-Tabellen-Kopfzeilen-Array veraltet und bezieht sich auf einen Eintrag, der zuvor aus dem Stack entfernt wurde. In einem solchen Fall wird die freigegebene Block-ID auf den Stack geschoben 514, das Hash-Tabellen-Kopfzeilen-Array mit der Eintragsposition der hinzugefügten Block-ID aktualisiert, der Hash-Link wird an seiner entsprechenden Eintragsposition für die zurückkehrende freigegebene Block-ID auf Null aktualisiert und der auf die Stackspitze weisende Zeiger erhöht 516.
Unter der Voraussetzung, dass der aktuelle, aus dem Umwandeln der freigegebenen Block-ID erhaltene Hash-Wert in der Hash-Tabelle auf eine Eintragsposition in dem Stack verweist, die niedriger als der auf die Stackspitze weisende Zeiger ist, wird eine Stackindex-Variable auf den aktuellen Hash-Wert gesetzt, und die Block-ID für diesen Stackindex wird vom Stack abgerufen, das heißt, die Block-ID in dem Stack, die den referenzierten Hash-Tabellen-Eintrag aufweist, wird abgerufen 518. Die Verarbeitung wandelt diese Block-ID dann in einen Hash-Wert um und ermittelt, ob das Ergebnis gleich dem aktuellen Hash-Wert ist 520. Wenn die Antwort „Nein” lautet, weist die Hash-Tabelle einen veralteten Eintrag auf, und die freigegebene Block-ID wird an der Stackspitze hinzugefügt 522, und das Hash-Tabellen-Kopfzeilen-Array wird so aktualisiert, dass es auf die Eintragsposition der freigegebenen Block-ID an der Stackspitze zeigt, der Hash-Link wird an der entsprechenden Eintragsposition auf einen Nullwert gesetzt, und die Stackspitze wird auf den nächsten Eintrag erhöht 524.
Wenn die abgerufene Block-ID geteilt durch 4091 gleich dem aktuellen Hash-Wert ist, entscheidet die Verarbeitung, ob die abgerufene Block-ID gleich der freigegebenen Block-ID ist, die an den Block-ID-Pool zurückgegeben wird 526. Wenn die Antwort „Ja” lautet, wurde ein Verdoppelungsfehler (duplicate error) erkannt, und es werden Diagnosedaten gesammelt, um die Analyse des Verdoppelungsfehlers 528 zu erleichtern, wodurch der Rückgabeprozess beendet wird. Andernfalls unterscheidet sich die freigegebene Block-ID von der in dem Stack referenzierten Block-ID, und es wurde eine echte Kollision erkannt, das heißt, es wurden zwei Block-IDs mit demselben Hash-Wert erkannt. In diesem Fall wird ein nächster Eintrag in der entsprechenden Kollisionskette in dem Hash-Link abgerufen, der aktuelle Stackindex gespeichert und der Stackindex mithilfe des Hash-Link-Felds aktualisiert 530, wonach die Verarbeitung ermittelt, ob bei ausschließlichem Referenzieren des Hash-Links der Stackindex höher oder gleich dem auf die Stackspitze weisenden Zeiger ist 532, wie in 5B gezeigt. Wenn die Antwort „Ja” lautet, wurde ein veralteter Eintrag erkannt, und der Hash-Link wird so aktualisiert, dass er auf die Stackspitze verweist, die freigegebene Block-ID wird an der Eintragsposition an der Stackspitze eingefügt und der auf die Stackspitze weisende Zeiger erhöht 534.
Unter der Voraussetzung, dass sich der Stackindex unterhalb der aktuellen Stackspitze befindet, wird die entsprechende Block-ID für diesen Stackindex abgerufen 536, und diese Block-ID geteilt durch 4091 wird mit dem aktuellen Hash-Wert verglichen 538. Sind beide gleich, kehrt der Prozess zurück und wird wiederholt, bis keine weiteren Kollisionen in der Kollisionskette erkannt werden. Diese Logik arbeitet sich im Wesentlichen in der entsprechenden Kollisionskette in dem Hash-Link vor, bis die Kollisionskette auf eine Eintragsposition über oder gleich dem auf die Stackspitze weisenden Zeiger oder auf einen nicht in den Stack gehörenden Eintrag (d. h. einen veralteten Eintrag) verweist oder ein doppelt vorhandener Eintrag erkannt wird. Unter der Voraussetzung, dass die abgerufene Block-ID geteilt durch 4091 sich von dem aktuellen Hash-Wert unterscheidet 538, wird die freigegebene Block-ID auf die Stackspitze geschoben 540, und der Hash-Link oder genauer gesagt die relevante Kollisionskette wird so aktualisiert, dass sie auf die Eintragsposition an der Stackspitze zeigt, an der sich die freigegebene Block-ID befand; die entsprechende Eintragsposition in dem Hash-Link für diese Position an der Stackspitze wird auf Null gesetzt, und der auf die Stackspitze weisende Zeiger wird so erhöht, dass er auf den nächsten Eintrag zeigt 542.
Die 6A bis 6H zeigen Beispiele für das Verwalten von Block-IDs mithilfe der Abruf- und Rückgabeprotokolle aus den 4 bis 5B.
6A veranschaulicht eine Ausführungsform eines Stacks 600, der 1 bis 4091 Eintragspositionen aufweist, von denen jede eine Block-ID eines Block-ID-Pools wie beispielsweise eines hier beschriebenen Block-ID-Pools aufweisen kann. Jede Eintragsposition in dem Stack verfügt über eine entsprechende Eintragsposition in einem dem Stack zugeordneten Hash-Link 610. Wie hier erläutert, dient der Hash-Link zum Darstellen von Kollisionsketten, wobei jede Kette mehrere Block-IDs in dem Stack 600 kennzeichnet, die in denselben Hash-Wert umgewandelt werden, ohne Duplikate voneinander zu sein. Das Hash-Tabellen-Kopfzeilen-Array 620 dient als ein Index für den Stack und enthält bei dem hier angeführten Beispiel die Eintragspositionen 0 bis 4090. Daher entspricht die Eintragsposition 0 einem Hash-Wert (bzw. einem Restwert) von 0, die Eintragsposition 1 entspricht einem Hash-Wert (bzw. einem Restwert) von 1, die Eintragsposition 2 entspricht einem Hash-Wert von 2 usw. Wie erwähnt, erhält man bei einem Beispiel den Hash-Wert durch Teilen der Block-ID durch 4091, d. h. die Anzahl der Eintragspositionen in dem Stack bei dieser Ausführungsform. In 6A sind der Stack, der Hash-Link und das Hash-Tabellen-Kopfzeilen-Array leer, mit Ausnahme einer Block-ID, das heißt, die Block-ID 00000002 ist an der Eintragsposition 1 in dem Stack 600 angeordnet und hat einen entsprechenden Hash-Wert von 2, was bedeutet, dass an der Eintragsposition 2 in dem Hash-Tabellen-Kopfzeilen-Array 620 ein Wert „1” als der Index angegeben ist, der auf die Stelle in dem Stack 600 zeigt, an der sich die Block-ID 00000002 befindet. In diesem Zusammenhang sollte beachtet werden, dass 00000002 geteilt durch 4091 gleich einem Rest (bzw. Hash-Wert) von 2 ist.
In 6B wird eine weitere freigegebene Block-ID, die Block-ID 00000001, an den Stack zurückgegeben und auf die Stackspitze an die in 6A gekennzeichnete Position geschoben, auf die der Stackzeiger (TOS, top-of-stack) weist. In diesem Zusammenhang sollte beachtet werden, dass bei diesem Beispiel der auf die Stackspitze weisende Zeiger immer auf die nächste freie Eintragsposition in dem Stack zeigt. Die Block-ID 00000001 geteilt durch 4091 ergibt einen Rest 1, der in dem Hash-Tabellen-Kopfzeilen-Array 620 an der zweiten Eintragsposition von links eingetragen wird, das heißt an der Eintragsposition „1”. An dieser Eintragsposition wird der Index 2 platziert, was darauf hinweist, dass die relevante Block-ID sich an der Eintragsposition 2 in dem Stack befindet. Es sollte beachtet werden, dass der Wert in dem Hash-Link sowohl für die Eintragsposition 1 als auch die Eintragsposition 2 bei Null bleibt, da zwischen den Hash-Werten der aktuell in dem Stack vorhandenen Block-IDs keine Kollision vorliegt.
In 6C wird eine weitere freigegebene Block-ID, die Block-ID 00004093, an der in 6B durch den auf die Stackspitze weisenden Zeiger gekennzeichneten Eintragsposition an der Stackspitze auf den Stack geschoben, das heißt, wie veranschaulicht, an die Eintragsposition „3” in dem Stack. Die Block-ID 00004093 hat einen Hash-Wert von 2, der mit der Block-ID 00000002 an der Eintragsposition 1 in dem Stack kollidiert. Daher fordert das Protokoll, dass eine Prüfung durchzuführen ist, bevor die freigegebene Block-ID 00004093 dem Stack hinzugefügt wird. Die Eintragsposition der Block-ID 00000002 ist die Eintragsposition 1 in dem Stack, was niedriger als die Stackspitze ist. Daher werden die Hash-Werte der Block-ID 00000002 und der Block-ID 00004093 bewertet, und es wird festgestellt, dass sie identisch sind, und dass die Block-IDs selbst sich voneinander unterscheiden. Da außerdem der entsprechende Eintrag in dem Hash-Link Null ist, wird die Block-ID 00004093 an der Stackspitze hinzugefügt, und es wird eine Kollisionskette in dem Hash-Link zwischen der Eintragsposition 1 und der Eintragsposition 3 erstellt, das heißt, die Eintragsposition 1 in dem Hash-Link zeigt auf die Eintragsposition 3, was bedeutet, dass die zugeordneten Block-IDs 000000002 und 00004093 durch die Kollisionskette miteinander in Zusammenhang stehen.
In 6D wird eine Block-ID von der Stackspitze geholt, was bei diesem Beispiel bedeutet, dass der durch die Block-ID 00004093 dargestellte Block entfernt wird. Es sollte beachtet werden, dass das Holen der Block-ID von der Stackspitze einfach bedeutet, dass der auf die Stackspitze weisende Zeiger um eine Position nach unten bewegt wird, was ein Freigeben des Blocks/der Block-ID ermöglicht, ohne nach der Freigabe der Block-ID die Eintragsposition in dem Stack zu aktualisieren. Wie vorstehend angemerkt, wird davon ausgegangen, dass der auf die Stackspitze weisende Zeiger auf die nächste freie Eintragsposition in dem Stack zeigt. Daher ist der Wert 00004093 in dem Beispiel aus 6D ein veralteter Block-ID-Eintrag in dem Stack und kann überschrieben werden (wie in 6E veranschaulicht), indem eine andere Block-ID, beispielsweise die Block-ID 00004092, an der Eintragsposition, auf die der auf die Stackspitze weisende Zeiger in 6D zeigt, auf den Stack geschoben wird.
Bei diesem Beispiel sollte beachtet werden, dass das Schieben der Block-ID 00004092 auf den Stack das Ermitteln eines zugeordneten Hash-Werts von 1 beinhaltet. Der Hash-Wert 1 wird in dem Hash-Tabellen-Kopfzeilen-Array, von der linken Position Null aus gezählt, an der Eintragsposition „1” eingetragen. Wie in 6E veranschaulicht, zeigt die Eintragsposition „1” in dem Hash-Tabellen-Kopfzeilen-Array auf die Eintragsposition 2 in dem Stack, das heißt auf die Block-ID 00000001. Da die Block-ID 00000001 und die Block-ID 00004092 in denselben Hash-Wert umgewandelt werden, wird eine neue Kollisionskette erkannt und der Hash-Link an der Eintragsposition „2” mit der Zahl „3” aktualisiert, so dass er auf die Eintragsposition „3” in dem Stack zeigt, um diese zwei Block-IDs zu korrelieren. In diesem Zusammenhang sollte beachtet werden, dass die 3 an der Eintragsposition 1 des Hash-Links veraltet bleibt.
In 6F wird eine weitere freigegebene Block-ID 00004093 auf den Stack geschoben. Das Protokoll zum Verwalten dieser Aktion folgt in seinem Verlauf dem vorstehend beschriebenen, abgesehen davon, dass jetzt der Link in dem in 6E für die Block-ID 00000002 referenzierten Hash-Link mit demselben Hash-Wert unter die Eintragsposition des auf die Stackspitze zeigenden Zeigers weist. Daher wird gemäß dem Protokoll die Block-ID an der Eintragsposition „3” überprüft (d. h. die Block-ID 00004092), und es wird ermittelt, dass sie sich nicht in derselben Kollisionskette wie die gerade freigegebene Block-ID 00004093 befindet, und daher wird die neue Block-ID 00004093 an der Stackspitze hinzugefügt, und der der Kollisionskette der Block-ID 00000002 zugeordnete Hash-Link wird so aktualisiert, dass er auf die Eintragsposition „4” in dem Stack zeigt.
In 6G soll gerade eine weitere freigegebene Block-ID 00008184 auf den Stack geschoben werden, und wie vorstehend mit Bezug auf 6F erwähnt, gibt es aktuell zwei in dem Hash-Link erkannte Kollisionsketten, das heißt, für Block-IDs, die in einen Hash-Wert von 1 umgewandelt werden und Block-IDs, die in einen Hash-Wert von 2 umgewandelt werden. Im Hinblick auf das Schieben der Block-ID 00008184 auf den Stack wird angemerkt, dass die Block-ID 00008184 in denselben Hash-Wert umgewandelt wird wie die Block-ID 0004093. Daher wird die Block-ID 00008184 an der Stackspitze hinzugefügt, da der in 6F erkannte Hash-Link der vierten Eintragsposition entspricht, das heißt, die Eintragsposition mit der Block-ID 00004093 ist Null. Weiter wird anschließend die entsprechende Kollisionskette aktualisiert, indem der Wert in dem Hash-Link an dieser Eintragsposition so aktualisiert wird, dass er auf die Eintragsposition „5” zeigt, wodurch auf der Grundlage von Hash-Werten die Block-IDs 00000002, 00004093 und 00008184 miteinander verkettet werden.
In 6H wird ein Versuch unternommen, den Block 00004093 wieder auf den Stack zu schieben, und dieser Fehler wird als ein Verdoppelungsfehler erkannt, da sich 00004093 bereits in dem Stack befindet. Durch Voranschreiten durch das Management-Protokoll aus den 5A und 5B und Feststellen, dass die Block-ID 00004093 in denselben Hash-Wert wie die Block-ID 000000002 umgewandelt wird, nämlich den Hash-Wert 2, schreitet die Verarbeitung durch die entsprechende Kollisionskette voran, bis erkannt wird, dass die Block-ID an der Eintragsposition „4” in dem Stack identisch mit der freigegebenen Block-ID ist, die dem Stack hinzugefügt werden soll.
Bei dem vorstehenden Beispiel sollte beachtet werden, dass Block-IDs als Dezimalzahlen vorliegen, und die Größe des Block-ID-Pools sollte als 4090 angenommen werden. Es sollte weiter beachtet werden, dass Block-IDs für einen 4-K-Zusatzspeicherpool oder einen 1-M-Zusatzspeicherpool realisiert werden können, und dass die Hash-Funktion einfach Block-ID geteilt durch 4091 lauten kann.
Es sollte auch beachtet werden, dass durch das in den 4 bis 5B gezeigte Protokoll keine zusätzliche Leistungseinbufle (performance overhead) entsteht, wenn eine Block-ID aus dem Pool abgerufen wird, und dass eine relativ geringe Leistungseinbufle entsteht, wenn eine Block-ID zwecks Rückgabe an den Pool freigegeben wird. Damit die Prüfung vollständig ist, müsste die freigegebene Block-ID-Logik außerdem auf Folgendes eingehen: Wenn der Pool voll ist, muss die Hashing-Suche dennoch ausgeführt werden, um sicherzustellen, dass keine doppelten freigegebenen Block-IDs vorhanden sind, obwohl sie nicht zu dem Pool hinzugefügt werden kann, und wenn die Block-ID zum Block-ID-Pool hinzugefügt wird, muss beim Blockmanager angefragt werden, um festzustellen, ob der Block, der zu dem Block-ID-Pool hinzugefügt wird, aus der Perspektive des Blockmanagers bereits freigegeben wurde.
Wie Fachleute verstehen werden, können Aspekte der vorliegenden Erfindung als ein System, Verfahren oder Computerprogrammprodukt verkörpert sein. Dementsprechend können Aspekte der vorliegenden Erfindung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (eingeschlossen Firmware, speicherresidente Software, Mikrocode usw.) oder die einer Ausführungsform annehmen, bei der Software- und Hardwareaspekte kombiniert werden, die hier alle allgemein als „Schaltung”, „Modul” oder „System” bezeichnet werden sollen. Aspekte der vorliegenden Erfindung können außerdem die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit in dem Medium verkörpertem computerlesbarem Programmcode verkörpert ist.
Es kann eine beliebige Kombination von einem oder mehreren computerlesbaren Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein.
Ein computerlesbares Signalmedium kann unter anderem ein verbreitetes Datensignal mit darin enthaltenem computerlesbarem Programmcode sein, zum Beispiel im Basisband oder als Teil einer Trägerwelle. Ein solches verbreitetes Signal kann verschiedene Formen annehmen, unter anderem, aber ohne darauf beschränkt zu sein, eine elektromagnetische oder optische Form oder eine beliebige geeignete Kombination aus diesen. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit übermitteln, verbreiten oder transportieren kann.
Ein computerlesbares Speichermedium kann beispielsweise, aber ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine derartige Vorrichtung oder Einheit oder jede beliebige Kombination von diesen sein. Als konkretere Beispiele (unvollständige Liste) für das computerlesbare Speichermedium könnten die folgenden aufgeführt werden: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer, programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact Disc-Nur-Lese-Speicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination von diesen. Im Zusammenhang dieses Dokuments kann ein computerlesbares Speichermedium ein beliebiges physisches Medium sein, das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit enthalten oder speichern kann.
Wie in 7 gezeigt, enthält bei einem Beispiel ein Computerprogrammprodukt 700 beispielsweise ein oder mehrere nicht flüchtige computerlesbare Speichermedien 702, zum Speichern von computerlesbaren Programmcodemitteln oder Logik 704 auf diesen, um einen oder mehrere Aspekte der vorliegenden Erfindung bereitzustellen und zu erleichtern.
Auf einem computerlesbaren Medium enthaltener Programmcode kann mithilfe eines geeigneten Mediums übermittelt werden, einschließlich, ohne darauf beschränkt zu sein, ein drahtloses oder drahtgebundenes Medium, Lichtwellenleiterkabel, Hochfrequenz (HF) usw. oder jede geeignete Kombination von diesen.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie beispielsweise Java, Smalltalk, C++ oder Ähnliche sowie herkömmliche verfahrensorientierte Programmiersprachen wie beispielsweise die Programmiersprache „C”, Assembler oder ähnliche Programmiersprachen. Der Programmcode kann vollständig oder teilweise auf dem Computer des Benutzers, als ein eigenständiges Softwarepaket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Bei dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch ein beliebiges Netzwerk, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) verbunden sein, oder es kann eine Verbindung mit einem externen Computer hergestellt werden (zum Beispiel mithilfe eines Internetdienstanbieters über das Internet).
Aspekte der vorliegenden Erfindung werden hier mit Bezug auf Ablaufpläne und/oder Blockschaltbilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaltbilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaltbildern durch Computerprogrammanweisungen realisiert werden können. Diese Computerprogrammanweisungen können für einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zur Herstellung einer Maschine bereitgestellt werden, so dass die Anweisungen, die durch den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Realisieren der in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaltbilds angegebenen Funktionen/Handlungen erzeugen.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Weise funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen ein Erzeugnis samt der Anweisungen herstellen, mithilfe derer die in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaltbilds angegebene Funktion/Handlung realisiert wird.
Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder den anderen Einheiten auszuführenden Betriebsschritten zu bewirken, um einen computerumgesetzten Prozess zu schaffen, so dass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Verfahren zur Realisierung der in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaltbilds angegebenen Funktionen/Handlungen bereitstellen.
Die Ablaufpläne und die Blockschaltbilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In dieser Beziehung kann jeder Block in den Ablaufplänen oder den Blockschaltbildern ein Modul, Segment oder einen Codeabschnitt enthalten, das/der eine oder mehrere ausführbare Anweisungen zur Realisierung der angegebenen Logikfunktion(en) aufweist. Es sollte auch beachtet werden, dass bei einigen alternativen Realisierungen die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten können. Zum Beispiel können zwei aufeinander folgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können in Abhängigkeit von der betreffenden Funktionalität manchmal in der umgekehrten Reihenfolge ausgeführt werden. Es ist ebenfalls zu beachten, dass jeder Block der Blockschaltbilder und/oder der Ablaufpläne sowie Blockkombinationen in den Blockschaltbildern und/oder den Ablaufplänen durch hardwarebasierte Spezialsysteme, die die angegebenen Funktionen oder Handlungen ausführen, oder Kombinationen von Spezialhardware und Computeranweisungen realisiert werden können.
Neben dem Vorstehenden können ein oder mehrere Aspekte der vorliegenden Erfindung von einem Dienstanbieter, der das Verwalten von Kundenumgebungen anbietet, bereitgestellt, angeboten, eingesetzt, verwaltet, gewartet usw. werden. Der Dienstanbieter kann beispielsweise für einen oder mehrere Kunden Computercode und/oder Computerinfrastruktur, mit dessen/deren Hilfe ein oder mehrere Aspekte der vorliegenden Erfindung ausgeführt werden, erstellen, unterhalten, unterstützen usw. Im Gegenzug kann der Dienstanbieter von dem Kunden beispielsweise Bezahlung aufgrund einer Abonnement- und/oder Gebührenvereinbarung erhalten. Zusätzlich oder alternativ kann der Dienstanbieter Bezahlung aus dem Verkauf von Werbeinhalt an einen oder mehrere Dritte erhalten.
Bei einem Aspekt der vorliegenden Erfindung kann eine Anwendung eingesetzt werden, um einen oder mehrere Aspekte der vorliegenden Erfindung auszuführen. Beispielsweise weist der Einsatz einer Anwendung das Bereitstellen von Computerinfrastruktur auf, die dafür geeignet ist, einen oder mehrere Aspekte der vorliegenden Erfindung auszuführen.
Als ein weiterer Aspekt der vorliegenden Erfindung kann eine Datenverarbeitungsinfrastruktur eingesetzt werden, die das Integrieren computerlesbaren Codes in ein Datenverarbeitungssystem aufweist, in dem der Code in Verbindung mit dem Datenverarbeitungssystem in der Lage ist, einen oder mehrere Aspekte der vorliegenden Erfindung auszuführen.
Als ein wieder anderer Aspekt der vorliegenden Erfindung kann ein Prozess zum Integrieren von Datenverarbeitungsinfrastruktur bereitgestellt werden, der das Integrieren von computerlesbarem Code in ein Computersystem aufweist. Das Computersystem weist ein computerlesbares Medium auf, wobei das computerlesbare Medium einen oder mehrere Aspekte der vorliegenden Erfindung aufweist. Der Code in Verbindung mit dem Computersystem ist in der Lage, einen oder mehrere Aspekte der vorliegenden Erfindung auszuführen.
Obwohl vorstehend verschiedene Ausführungsformen beschrieben werden, sind diese lediglich Beispiele. Beispielsweise können in Datenverarbeitungsumgebungen, die andere Architekturen aufweisen, ein oder mehrere Aspekte der vorliegenden Erfindung enthalten sein und verwendet werden. Obwohl hier Beispiele für Zusatzspeicher beschrieben werden, können andere Arten von Zusatzspeicher verwendet werden, ohne vom Erfindungsgedanken der vorliegenden Erfindung abzuweichen. Überdies können andere Erwägungen angestellt werden, um zu ermitteln, wann oder auf welche Weise die Pools großer Speicherseiten (large page pools) zu verwalten sind. Außerdem können gemäß einem Aspekt der vorliegenden Erfindung auch andere Pools als Pools großer Speicherseiten verwaltet werden. Darüber hinaus können andere Schwellenwerte und/oder Prozentanteile verwendet werden.
Überdies können ein oder mehrere Aspekte der vorliegenden Erfindung für andere Arten von Datenverarbeitungsumgebungen vorteilhaft sein. Eine Umgebung kann beispielsweise einen Emulator enthalten (z. B. Software oder andere Emulationsmechanismen), in dem eine bestimmte Architektur (darunter beispielsweise Anweisungsausführung, architekturdefinierte Funktionen wie beispielsweise Adressumsetzung und architekturdefinierte Register) oder eine Teilmenge davon emuliert wird (z. B. auf einem nativen Computersystem mit einem Prozessor und Speicher). In einer solchen Umgebung können durch eine oder mehrere Emulationsfunktionen des Emulators ein oder mehrere Aspekte der vorliegenden Erfindung realisiert werden, obwohl ein Computer, auf dem der Emulator ausgeführt wird, eine andere Architektur als die emulierten Fähigkeiten aufweisen kann. Beispielsweise wird im Emulationsmodus die spezielle Anweisung oder Operation, die emuliert wird, decodiert, und es wird eine geeignete Emulationsfunktion erstellt, um die einzelne Anweisung oder Operation zu realisieren.
In einer Emulationsumgebung enthält ein Hostcomputer beispielsweise einen Speicher zum Speichern von Anweisungen und Daten; eine Anweisungsabrufeinheit zum Abrufen von Anweisungen aus dem Speicher und um wahlweise eine lokale Pufferung für die abgerufene Anweisung bereitzustellen; eine Anweisungsdecodiereinheit zum Empfangen der abgerufenen Anweisungen und zum Ermitteln der Art der abgerufenen Anweisungen und eine Anweisungsausführungseinheit zum Ausführen der Anweisungen. Das Ausführen kann das Laden von Daten aus dem Speicher in ein Register beinhalten, das Zurückspeichern von Daten aus einem Register in den Speicher oder das Ausführen einer Art arithmetischer oder logischer Operation, die durch die Decodiereinheit festgelegt wird. Bei einem Beispiel ist jede Einheit in Software realisiert. Beispielsweise werden die von den Einheiten ausgeführten Operationen als eine oder mehrere Subroutinen in Emulator-Software realisiert.
Außerdem kann ein Datenverarbeitungssystem verwendet werden, das zum Speichern und/oder Ausführen von Programmcode geeignet ist, und das mindestens einen Prozessor enthält, der durch einen Systembus direkt oder indirekt mit Speicherelementen verbunden ist. Die Speicherelemente können beispielsweise lokalen Speicher enthalten, der während der tatsächlichen Ausführung des Programmcodes genutzt wird, Massenspeicher und Cachespeicher, in dem zumindest ein Teil des Programmcodes vorübergehend gespeichert wird, damit Code bei der Ausführung weniger häufig aus dem Massenspeicher abgerufen werden muss.
Eingabe-/Ausgabe- bzw. E-/A-Einheiten (einschließlich, ohne darauf beschränkt zu sein, Tastaturen, Bildschirme, Zeigeeinheiten, DASDs, Bandlaufwerke, CDs, DVDs, Thumb-Drives sowie andere Speichermedien usw. können entweder direkt oder mithilfe von dazwischen liegenden E-/A-Controllern mit dem System verbunden sein. Auch Netzwerkadapter können mit dem System verbunden sein, damit das Datenverarbeitungssystem mit anderen Datenverarbeitungssystemen oder Remote-Druckern oder Speichereinheiten durch dazwischen liegende private oder öffentliche Netzwerke verbunden werden kann. Modems, Kabelmodems und Ethernet-Karten sind nur einige der verfügbaren Arten von Netzwerkadaptern.
Die hier verwendete Terminologie dient ausschließlich dem Zweck der Beschreibung bestimmter Ausführungsformen und soll die Erfindung nicht einschränken. Die Singularformen unbestimmter und bestimmter Artikel wie „ein”, „eine” und „der”, „die”, „das” sollen ebenfalls die Pluralformen beinhalten, solange der Kontext nicht eindeutig auf etwas anderes hinweist. Es sollte weiter beachtet werden, dass die Begriffe „aufweisen” (und jede Form von „aufweisen” wie beispielsweise „weist auf” und „aufweisend”), „haben” (und jede Form von „haben” wie beispielsweise „hat” und „habend”), „beinhalten” (und jede Form von „beinhalten” wie beispielsweise „beinhaltet” und „beinhaltend”) und „enthalten” (und jede Form von „enthalten” wie beispielsweise „enthält” und „enthaltend”) „ergebnisoffene” Verbindungsverben (open-ended linking verbs) sind. Folglich verfügen ein Verfahren oder eine Einheit, die einen oder mehrere Schritte oder ein oder mehrere Elemente „aufweisen”, „haben”, „beinhalten” oder „enthalten” über diesen Schritt oder dieses Element bzw. diese Schritte oder Elemente, sind aber nicht darauf beschränkt, nur über diesen Schritt oder diese Schritte oder dieses Element oder diese Elemente zu verfügen. In ähnlicher Weise verfügt ein Schritt eines Verfahrens oder ein Element einer Einheit, der/das ein oder mehrere Merkmale „aufweist”, „hat”, „beinhaltet” oder „enthält” über dieses Merkmal oder diese Merkmale, ist aber nicht darauf beschränkt, nur über dieses Merkmal oder diese Merkmale zu verfügen. Darüber hinaus ist eine Einheit oder Struktur, die auf eine bestimmte Weise gestaltet ist, mindestens auf diese Weise gestaltet, kann aber auch auf Arten gestaltet sein, die nicht aufgeführt sind.
Die entsprechenden Strukturen, Materialien, Handlungen sowie Äquivalente aller Mittel oder Schritt-und-Funktion-Elemente (step plus function elements) in den folgenden Ansprüchen, soweit vorhanden, sollen jede beliebige Struktur, jedes beliebige Material oder jede beliebige Handlung zum Ausführen der Funktion in Verbindung mit anderen beanspruchten Elementen als ausdrücklich beansprucht beinhalten. Die Beschreibung der vorliegenden Erfindung wird zum Zweck der Veranschaulichung und Beschreibung vorgelegt und soll nicht vollständig oder auf die offenbarte Form der Erfindung beschränkt sein. Für Fachleute werden zahlreiche Abänderungen und Abwandlungen offensichtlich sein, die aber keine Abweichung vom Schutzumfang der Erfindung und dem Erfindungsgedanken darstellen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Prinzipien der Erfindung und die praktische Anwendung bestmöglich zu erläutern, und um Fachleute in die Lage zu versetzen, die Erfindung im Hinblick auf verschiedene Ausführungsformen mit verschiedenen Abänderungen zu verstehen, die für die spezielle, in Betracht gezogene Verwendung geeignet sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

„z/Architecture Principles of Operation”, IBM Publication No. SA22-7832-08, August 2010 [0023]

Claims

Computerprogrammprodukt zum Verwalten von Speicher-IDs in einem Pool, wobei das Computerprogrammprodukt aufweist: ein von einer Verarbeitungsschaltung lesbares computerlesbares Speichermedium, auf dem Anweisungen zum Ausführen durch die Verarbeitungsschaltung zwecks Ausführens eines Verfahrens gespeichert sind, das aufweist: Realisieren eines Hashing-basierten Management-Protokolls in Verbindung mit einem Stack, der Speicher-IDs des Pools enthält, wobei das Hashing-basierte Management-Protokoll aufweist: auf der Grundlage einer Anforderung Holen einer Speicher-ID von dem Stack, ohne einen dem Stack zugeordneten Hash-Link im Hinblick auf eine Aktualisierung zu bewerten, wobei möglicherweise zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und auf der Grundlage der Rückgabe einer freigegebenen Speicher-ID an den Stack Umwandeln der freigegebenen Speicher-ID in einen Hash-Wert und Erkennen, ob in dem Hash-Link, der mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang steht, eine Inkonsistenz vorhanden ist, und auf der Grundlage des Erkennens der Inkonsistenz entweder Aktualisieren des Hash-Links, um die Inkonsistenz zu beseitigen, oder Anzeigen, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde.
Computerprogrammprodukt nach Anspruch 1, wobei der Hash-Link N Eintragspositionen aufweist, die N Eintragspositionen für Speicher-IDs in dem Stack entsprechen, und wobei bei dem Hashing-basierten Management-Protokoll außerdem ein dem Stack und dem Hash-Link zugeordnetes Hash-Tabellen-Kopfzeilen-Array verwendet wird, wobei das Hash-Tabellen-Kopfzeilen-Array durch Hash-Werte indiziert ist und Eintragspositionen von Speicher-IDs in dem Stack aufweist, und wobei der Hash-Link darauf hinweist, ob eine oder mehrere Kollisionsketten vorhanden sind, wobei jede Kollisionskette eine oder mehrere Speicher-IDs in dem Stack verbindet, die in denselben Hash-Wert umgewandelt werden.
Computerprogrammprodukt nach Anspruch 2, wobei der Stack, der Hash-Link und das Hash-Tabellen-Kopfzeilen-Array jeweils N Eintragspositionen aufweisen, wobei der Stack und der Hash-Link die Eintragspositionen 1 bis N aufweisen und das Hash-Tabellen-Kopfzeilen-Array die Eintragspositionen 0 bis N – 1 aufweist.
Computerprogrammprodukt nach Anspruch 2, wobei das Umwandeln in einen Hash-Wert das Erhalten eines Hash-Werts für die freigegebene Speicher-ID aufweist, und das Erkennen das Verwenden des Hash-Werts der freigegebenen Speicher-ID für die Ermittlung aufweist, ob in dem mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang stehenden Hash-Link die Inkonsistenz vorhanden ist.
Computerprogrammprodukt nach Anspruch 4, wobei auf der Grundlage dessen, dass die freigegebene Speicher-ID identisch mit einer Speicher-ID in dem Stack ist, von der erkannt wurde, dass sie auf eine Kollisionskette in dem Hash-Link verweist, was durch Verwenden der freigegebenen Speicher-ID und des Hash-Tabellen-Kopfzeilen-Array erreicht wurde, wobei angezeigt wird, dass die freigegebene Speicher-ID die doppelt vorhandene Speicher-ID ist.
Computerprogrammprodukt nach Anspruch 4, das weiter das Ermitteln aufweist, ob eine Eintragsposition in dem Hash-Tabellen-Kopfzeilen-Array, auf die der Hash-Wert verweist, leer ist, und auf der Grundlage des Ermittelns, dass diese Eintragsposition in dem Hash-Tabellen-Kopfzeilen-Array leer ist, Schieben der freigegebenen Speicher-ID auf den Stack, Aktualisieren des Hash-Tabellen-Kopfzeilen-Arrays mit der Eintragsposition der freigegebenen Speicher-ID in dem Stack, und Erhöhen eines dem Stack zugeordneten auf die Stackspitze weisenden Zeigers.
Computerprogrammprodukt nach Anspruch 6, das weiter aufweist, auf der Grundlage, dass die Eintragsposition in dem Hash-Tabellen-Kopfzeilen-Array, auf die der Hash-Wert verweist, nicht leer ist, das Ermitteln, ob dieser nicht leere Wert in dem Hash-Tabellen-Kopfzeilen-Array auf eine Kollisionskette in dem Hash-Link mit einem veralteten Eintrag an dem oder oberhalb des auf die Stackspitze weisenden Zeigers verweist, und auf der Grundlage des Erkennens des veralteten Eintrags an dem oder oberhalb des auf die Stackspitze weisenden Zeigers Schieben der freigegebenen Speicher-ID auf den Stack, Aktualisieren des Hash-Tabellen-Kopfzeilen-Arrays mit der Eintragsposition der freigegebenen Speicher-ID in dem Stack, und Erhöhen eines dem Stack zugeordneten auf die Stackspitze weisenden Zeigers.
Computerprogrammprodukt nach Anspruch 4, wobei das Erkennen weiter das Ermitteln im Hinblick auf jeden Eintrag in einer Kollisionskette in dem Hash-Link aufweist, der durch Verwenden des erhaltenen Hash-Werts und des Hash-Tabellen-Kopfzeilen-Arrays erreicht wird, ob dieser Eintrag einer Speicher-ID zugeordnet ist, die mit der freigegebenen Speicher-ID identisch ist, und als Reaktion darauf, dass die freigegebene Speicher-ID sich von jeder dieser Kollisionskette des Hash-Links zugeordneten Speicher-ID unterscheidet, Schieben der freigegebenen Speicher-ID auf den Stack, Aktualisieren der Kollisionskette in dem Hash-Link, so dass diese die Eintragsposition der freigegebenen Speicher-ID in dem Stack enthält, und Erhöhen eines dem Stack zugeordneten auf die Stackspitze weisenden Zeigers.
Computersystem zum Verwalten von Speicher-IDs in einem Pool, wobei das Computersystem aufweist: einen Speicher und einen Prozessor, der Daten mit dem Speicher austauscht, wobei das Computersystem dafür konfiguriert ist, ein Verfahren auszuführen, wobei das Verfahren aufweist: Realisieren eines Hashing-basierten Management-Protokolls in Verbindung mit einem Stack, der Speicher-IDs des Pools enthält, wobei das Hashing-basierte Management-Protokoll aufweist: auf der Grundlage einer Anforderung Holen einer Speicher-ID von dem Stack, ohne einen dem Stack zugeordneten Hash-Link im Hinblick auf eine Aktualisierung zu bewerten, wobei möglicherweise zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und auf der Grundlage der Rückgabe einer freigegebenen Speicher-ID an den Stack Umwandeln der freigegebenen Speicher-ID in einen Hash-Wert und Erkennen, ob in dem Hash-Link, der mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang steht, eine Inkonsistenz vorhanden ist, und auf der Grundlage des Erkennens der Inkonsistenz entweder Aktualisieren des Hash-Links, um die Inkonsistenz zu beseitigen, oder Anzeigen, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde.
Computersystem nach Anspruch 9, wobei der Hash-Link N Eintragspositionen aufweist, die den N Eintragspositionen für Speicher-IDs in dem Stack entsprechen, und wobei bei dem Hashing-basierten Management-Protokoll außerdem ein dem Stack und dem Hash-Link zugeordnetes Hash-Tabellen-Kopfzeilen-Array verwendet wird, wobei das Hash-Tabellen-Kopfzeilen-Array durch Hash-Werte indiziert ist und Eintragspositionen von Speicher-IDs in dem Stack aufweist, und wobei der Hash-Link darauf hinweist, ob eine oder mehrere Kollisionsketten vorhanden sind, wobei jede Kollisionskette zwei oder mehrere Speicher-IDs in dem Stack verbindet, die in denselben Hash-Wert umgewandelt werden.
Computersystem nach Anspruch 10, wobei das Umwandeln in einen Hash-Wert das Erhalten eines Hash-Werts für die freigegebene Speicher-ID aufweist, und das Erkennen das Verwenden des Hash-Werts der freigegebenen Speicher-ID für die Ermittlung aufweist, ob in dem mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang stehenden Hash-Link die Inkonsistenz vorhanden ist.
Computersystem nach Anspruch 11, das weiter das Ermitteln aufweist, ob eine Eintragsposition in dem Hash-Tabellen-Kopfzeilen-Array, auf die der Hash-Wert verweist, leer ist, und auf der Grundlage des Ermittelns, dass diese Eintragsposition in dem Hash-Tabellen-Kopfzeilen-Array leer ist, Schieben der freigegebenen Speicher-ID auf den Stack, Aktualisieren des dem Stack zugeordneten Hash-Tabellen-Kopfzeilen-Arrays mit der Eintragsposition der freigegebenen Speicher-ID in dem Stack, und Erhöhen eines dem Stack zugeordneten auf die Stackspitze weisenden Zeigers.
Verfahren zum Verwalten von Speicher-IDs in einem Pool, wobei das Verfahren aufweist: Realisieren, mithilfe eines Prozessors, eines Hashing-basierten Management-Protokolls in Verbindung mit einem Stack, der Speicher-IDs des Pools enthält, wobei das Hashing-basierte Management-Protokoll aufweist: auf der Grundlage einer Anforderung Holen einer Speicher-ID von dem Stack, ohne einen dem Stack zugeordneten Hash-Link im Hinblick auf eine Aktualisierung zu bewerten, wobei möglicherweise zugelassen wird, dass der Hash-Link mit in dem Stack verbleibenden Speicher-IDs inkonsistent wird, und auf der Grundlage der Rückgabe einer freigegebenen Speicher-ID an den Stack Umwandeln der freigegebenen Speicher-ID in einen Hash-Wert und Erkennen, ob in dem Hash-Link, der mit der Rückgabe der freigegebenen Speicher-ID in Zusammenhang steht, eine Inkonsistenz vorhanden ist, und auf der Grundlage des Erkennens der Inkonsistenz entweder Aktualisieren des Hash-Links, um die Inkonsistenz zu beseitigen, oder Anzeigen, dass die freigegebene Speicher-ID eine doppelt vorhandene Speicher-ID ist, wenn dies festgestellt wurde.