DE69637329T2 - Speichermanagementsystem und verfahren - Google Patents

Speichermanagementsystem und verfahren Download PDF

Info

Publication number
DE69637329T2
DE69637329T2 DE69637329T DE69637329T DE69637329T2 DE 69637329 T2 DE69637329 T2 DE 69637329T2 DE 69637329 T DE69637329 T DE 69637329T DE 69637329 T DE69637329 T DE 69637329T DE 69637329 T2 DE69637329 T2 DE 69637329T2
Authority
DE
Germany
Prior art keywords
block
memory
list
size
page
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69637329T
Other languages
English (en)
Other versions
DE69637329D1 (de
Inventor
Michael W. Pasadena MCCOOL
Scott J. Wenatchee KURMAN
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.)
Sand Technology Inc
Original Assignee
Sand Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/565,862 external-priority patent/US5835959A/en
Application filed by Sand Technology Inc filed Critical Sand Technology Inc
Publication of DE69637329D1 publication Critical patent/DE69637329D1/de
Application granted granted Critical
Publication of DE69637329T2 publication Critical patent/DE69637329T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Description

  • Querverweis auf eine zugehörige Anmeldung
  • Dies ist eine Teilfortsetzungsanmeldung („continuation-in-gart”) der anhängigen provisorischen US-Patentanmeldung Nr. 60/003,117 vom 31. August 1995 mit dem Titel „Speicherverwaltungssystem und -verfahren".
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Speichermanagementsystem und -verfahren und insbesondere ein Speichermanagementsystem und -verfahren zum Zuweisen eines Speicherblockes bei einem hierarchisch organisierten Speicher in gleichbleibender Zeit.
  • Hintergrund der Erfindung
  • Bei jedem Computer ist die physikalische Speichergröße endlich, ob der Speicher ein flüchtiger Speicher (sogenannter Speicherpuffer, „cache"), der Hauptspeicher oder ein externer Speicher ist. Allerdings müssen datenintensive Anwendungen wie Datenbankmanagementsysteme mit Datendateien arbeiten, die in einem externen Speicher vorgehalten werden, dessen Gesamtgröße die Kapazität des Speicherpuffers oder des Hauptspeichers bei weitem übersteigt. Als eine Lösung wurde virtueller Speicher entwickelt, um einen Zugang zu diesen quasi unendlich großen Dateien zu schaffen, auch wenn durch die physikalische Speicherhardware Beschränkungen bestehen.
  • Bei einem typischen virtuellen Speichersystem wird die Datei in einzelne, identisch dimensionierte Dateneinheiten unterteilt, die ohne Probleme mit den Grenzen des Hauptspeichers zusammen passen. Ein Bereich des Hauptspeichers wird in einen Über lagerungsbereich partitioniert, der eine Anzahl von identisch dimensionierten Seiten zum Abspeichern ausgewählter Dateneinheiten aufweist. Die Dateneinheiten und Seiten haben die gleiche Größe, so dass jede Seite dazu eingerichtet ist, eine Dateneinheit aufzunehmen. Dateneinheiten werden auf Anforderung eines Anwendungsprogramms dynamisch in die Seiten geladen und auf den externen Speicher ausgelagert, wenn die Seite zum Laden einer anderen Dateneinheit benötigt wird. Virtueller Speicher im Allgemeinen wird in A.S. Tanenbaum, Structured Computer Organization, Seiten 308–41, Prentice-Hall (2. Auflage 1984) erläutert.
  • Jede bestimmte Dateneinheit kann zugewiesene Speicherblöcke oder nicht zugewiesene Speicherblöcke, das heißt freien Speicher, enthalten. Virtueller Speicher stellt keine effiziente Vorgehensweise zum Zuweisen dieses zufällig verteilten freien Bereiches zum Abspeichern von Dateninhalten mit variablen Größen bereit, die während der Programmausführung erzeugt werden. Er behandelt nur das Problem des Ladens von angeforderten Dateneinheiten einer Datei in den Hauptspeicher, die selbst zu groß ist, um effizient in den Hauptspeicher zu passen. Daher gibt es einen Bedarf für eine systematische Vorgehensweise zum dynamischen Zuweisen verfügbarer Speicherblöcke, die in dem Dateneinheitenbereich in variabel dimensionierten Abschnitten liegen, um sie durch ein Anwendungsprogramm zu nutzen.
  • Eine systematische Vorgehensweise zum dynamischen Zuweisen von Speicherblöcken von Dateninhalten ist als das „Buddy Block System", wie es in D.E. Knuth, The Art of Computer Programming, Band 1, Seiten 442–45, Addison-Wesley (1973) beschrieben ist. Jede Dateneinheit wird in proportionale, fest dimensionierte Speicherblöcke mit jeweils einer Größe, die eine Potenz von 2 ist, unterteilt. Speicherblöcke werden nur einer dieser vorbestimmten Größen dynamisch zugewiesen. Ein Über schuss an Speicher wird verschwendet, wenn die zugewiesene Speicherblockgröße größer als die angeforderte Größe ist.
  • Jede Dateneinheit ist mit einer Kopfstruktur zum Beschreiben der Attribute der Dateneinheit verknüpft. Die Dateneinheitenköpfe sind zweifach miteinander in einer Liste verknüpft, die so viele Dateneinheitenköpfe wie die Datei Dateneinheiten hat. Weiterhin kann jede Dateneinheit so viele verknüpfte Listen von Speicherblockköpfen haben wie die Dateneinheit Speicherblockgrößen aufweist. Die Listenköpfe dieser Speicherblocklisten sind in dem Dateneinheitenkopf enthalten. Jeder Dateneinheitenkopf enthält weiterhin eine Verfügbarkeitsbitfolge, um anzugeben, welche Speicherblockgrößen innerhalb der Dateneinheit frei sind. Die Dateneinheitenköpfe sind unter Ausbilden von "Kopf"-Dateneinheiten physikalisch gruppiert und sollten von Dateneinheiten unterscheidbar sein, da sie beim Beschränken der Leistungsfähigkeit eine besondere Rolle spielen.
  • Bei dieser Vorgehensweise vom Zuweisen von Speicher gibt es zwei Probleme. Als erstes ist die Vorgehensweise speicherplatzeffizient, aber zeitineffizient. Mit zunehmender Dateigröße, das heißt mit zunehmender Anzahl von Dateneinheiten mit Daten, werden proportional weniger Kopfdateneinheiten der Datei in dem Überlagerungsbereich bleiben, was eine Zunahme der Zeit verursacht, die erforderlich ist, um eine Bereichszuweisung bei einer immer höher werdenden Anzahl von Eingangs- und Ausgangs-(I/O-)Operationen unter Abruf von Kopfdateneinheiten durchzuführen. Somit nimmt die systematische Vorgehensweise einen proportional größeren Zeitraum zum Zuweisen von Speicherblöcken bei Zunahme des virtuellen Speichers ein. Um einen freien Speicherblock zu finden, wird als erstes die Speicherblockgröße mit der kleinsten Potenz von 2 gewählt, die wenigstens so groß wie die nachgefragte Speichergröße ist. Die verknüpfte Liste von Dateneinheitenköpfen wird durchgegangen, was zu einem Kopfdateneinheiten-I/O führt, und jede Verfügbar keitsbitfolge wird untersucht, um eine Dateneinheit mit einem freien Speicherblock der gewünschten Größe als Potenz von 2 zu finden. Es wird die gesamte verknüpfte Liste durchsucht, bis ein freier Speicherblock gefunden ist. Falls kein Block gefunden worden ist, wird die Speicherblockgröße der nächsten Potenz von 2 ausgewählt, und der Durchgang wird wiederholt. Dieser gesamte Vorgang wird wiederholt, bis ein freier Speicherblock gefunden ist. Falls kein freier Speicherblock gefunden worden ist, wird eine neue Dateneinheit erzeugt, und es wird ein neuer Speicherblock zugewiesen. Während dieses Vorgangs wird auf die Dateneinheiten mit Daten nicht zugegriffen. Es werden lediglich Kopfdateneinheiten untersucht.
  • Als zweites kann Flattern („thrashing") auftreten. Es werden lediglich einige der Kopfdateneinheiten in dem Hauptspeicher gespeichert, und diejenigen, die während eines Suchdurchlaufs benötigt werden, müssen in den Speicher verlagert werden. Falls mehrere Suchdurchläufe benötigt werden, um einen freien Speicherblock zu finden, werden Kopfdateneinheiten hin- und herverlagert, bis die Speicheranfrage erledigt ist. Dies führt zu einer erheblichen Verringerung der Leistungsfähigkeit.
  • Daher gibt es einen Bedarf für ein System und ein Verfahren zum Handhaben einer Anfrage nach einem freien Speicherblock innerhalb einer Dateneinheit in einer gleichbleibenden Zeit, um die Notwendigkeit zu vermeiden; die gesamten Dateneinheitenkopfblocklisten zu durchsuchen, bis ein freier Speicherblock gefunden ist.
  • Das IBM Technical Disclosure Bulletin, Band 17, Nummer 11, 1975-04-01, Seiten 3252–3259 offenbart einen Mechanismus zum Nachverfolgen von nicht benutzten Bereichen auf Speicherseiten.
  • JP-A-06202936 offenbart einen freien Speichermanager, der das schnelle Zuweisen und die Rückgabe von Speicherblöcken für einen Hauptspeicher erleichtert.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung ermöglicht es, die oben genannten Probleme zu überwinden, indem sie ein Speichermanagementsystem und -verfahren zum Bereitstellen eines Speicherblockes in gleichbleibender Zeit schafft.
  • Gemäß der vorliegenden Erfindung ist ein Speicherverwaltungssystem für einen Datenspeicher geschaffen, wobei das Speicherverwaltungssystem eine Speichereinheit, die mit wenigstens einer Datei aufgebaut ist, welche Dateneinheiten mit gespeicherten Daten aufweist, einen Speicher, der mit Nummern versehene Seiten zum Speichern überlagerter Dateneinheiten der gespeicherten Daten von der Speichereinheit aufweist, wobei der Speicher weiterhin über eine Seitenlistenkopfliste, die über eine Anzahl von Listenkopfeinträgen verfügt, wobei jeder Eintrag der Anzahl von Listenkopfeinträgen eine Seite in dem Speicher identifiziert, der eine Dateneinheit speichert, die wenigstens einen freien Speicherblock einer bestimmten Größe aufweist, wobei die Seitenlistenkopfliste auf der Grundlage der freien Speicherblockgrößen aufgebaut ist, und über eine Laufwerkblockliste verfügt, die die eine Anzahl von Zählereinträgen aufweist, wobei jeder Eintrag in der Anzahl der Zählereinträge die Nummern der Dateneinheiten in der Speichereinheit umfasst, die wenigstens einen freien Speicherblock einer bestimmten Größe haben, und einen mit dem Speicher verbundenen Prozessor aufweist, wobei der Prozessor Mittel zum Abfragen der Seitenlistenkopfliste zum Erkennen einer Existenz eines bestimmten ersten Eintrags, der eine Seite in dem Speicher identifiziert, der eine Dateneinheit mit wenigstens einem freien Speicherblock einer in einer Speicher anfrage nachgefragten Größe speichert, und auf eine erfolglose Abfrage der Seitenlistenkopfliste reagierende Mittel zum Abfragen der Laufwerkblockliste zum Erkennen der Existenz eines die Anzahl der Dateneinheiten umfassenden Zähleintrags in der Speichereinheit aufweist, der wenigstens einen freien Speicherblock der in der Speicheranfrage nachgefragten Größe aufweist.
  • Die vorliegende Erfindung schafft weiterhin ein Verfahren zum Einsatz mit einem Computer zum Zuordnen eines Speicherblockes mit einer nachgefragten Größe, wobei der Computer über einen Speicher, der über mit Zählern versehene Seiten verfügt, um überlagerte Dateneinheiten von gespeicherten Daten aus einer Speichereinheit zu speichern, über eine Seitenlistenkopflist und über eine Laufwerkblockliste verfügt, wobei die Seitenlistenkopfliste eine Anzahl von Listenkopfeinträgen aufweist, wobei jeder Eintrag in der Anzahl von Listenkopfeinträgen eine Seite in dem Speicher identifiziert, die eine Dateneinheit speichert, die wenigstens einen freien Speicherblock einer bestimmten Größe aufweist, wobei die Seitenlistenkopflisten auf der Grundlage von freien Speicherblockgrößen aufgebaut sind und wobei die Laufwerkblockliste eine Anzahl von Zählereinträgen aufweist, wobei jeder Eintrag in der Anzahl von Zählereinträgen die Nummer von Dateneinheiten in der Speichereinheit umfasst, die wenigstens einen freien Speicherblock einer bestimmten Größe aufweisen, wobei das Verfahren den Empfang einer Speicheranfrage für einen Speicherblock mit einer nachgefragten Größe aufweist, das gekennzeichnet ist durch Abfragen der Seitenlistenkopfliste, die auf die Speicheranfrage reagierend ist, um die Existenz eines bestimmten Listenkopfeintrags festzustellen, der eine Seite in dem Speicher identifiziert, die eine Dateneinheit mit wenigstens einem freien Speicherblock der in der Speicheranfrage nachgefragten Größe aufweist, als Reaktion auf eine erfolglose Abfrage der Seitenlistenkopfliste Abfragen der Laufwerkblocklisten zum Feststellen der Existenz eines bestimmten die Nummer der Dateneinheiten enthaltenden Zählereintrags in der Speichereinheit, der wenigstens einen freien Speicherblock der in der Speicheranfrage nachgefragten Größe aufweist, und Zuordnen eines Speicherblocks mit der in der Speicheranfrage nachgefragten Größe.
  • Weitere Ausführungsbeispiele der vorliegenden Erfindung ergeben sich für die Fachleute ohne weiteres aus der nachfolgenden detaillierten Beschreibung, wobei Ausführungsbeispiele der Erfindung lediglich zum Veranschaulichen der besten Ausgestaltungen, die zum Ausführen der Erfindung in Betracht gezogen werden, beispielhaft dargestellt und beschrieben sind. Entsprechend sind die Zeichnungen und die detaillierte Beschreibung als in ihrer Natur lediglich beispielhaft und nicht einschränkend anzusehen.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein funkionales Blockschaubild eines Speichermanagementsystems gemäß der vorliegenden Erfindung,
  • 2 ist ein Blockschaubild der Speicher- und Laufwerkuntersystemkomponenten des in 1 dargestellten Speichermanagementsystems,
  • 3 ist ein Blockschaubild von Dateneinheiten, Verfügbarkeitsbitfolgen und freien Speicherblöcken in dem Speicher,
  • 4 ist ein Blockschaubild einer Datenbankdatei,
  • 5 und 6 sind Blockschaubilder des Speicherpuffers, einer Poolseitenlistenkopfliste und einer Poollaufwerkblockliste gemäß der vorliegenden Erfindung,
  • 7 ist ein Flussschaubild eines Verfahrens zur Speicherverwaltung gemäß der vorliegenden Erfindung,
  • 8 ist eine Datenstruktur einer Seite eines Speicherpuffersteuerfeldelementes,
  • 9 ist eine Datenstruktur eines Poolseitenlistenelementes,
  • 10 ist eine Datenstruktur eines Dateneinheitenkopfelementes,
  • 11 ist eine Datenstruktur eines Speicherblockkopfelementes,
  • 12 ist eine Datenstruktur einer Poolseitenlistenkopfliste,
  • 13 ist eine Datenstruktur einer Poollaufwerksblockliste,
  • 14 ist ein Flussschaubild einer Prozedur zum Erhalt eines Speicherblockes gemäß der vorliegenden Erfindung,
  • 15 ist ein Flussschaubild einer Prozedur zum Abfragen der Poolseitenlistenkopfliste,
  • 16 ist ein Flussschaubild einer Prozedur zum Zuweisen eines Speicherblockes,
  • 17 ist ein Flussschaubild einer Prozedur zum Aktualisieren der Blockversatzliste und der Blockköpfe,
  • 18 ist ein Flussschaubild einer Prozedur zum Abgleichen von Poolseitenlistenkopflisten,
  • 19 ist ein Flussschaubild einer Prozedur zum Hinzufügen einer Seite zu der Poolseitenlistenkopfliste,
  • 20 ist ein Flussschaubild einer Prozedur zum Beseitigen einer Seite von einer Poolseitenliste,
  • 21 ist ein Flussschaubild einer Prozedur zum Freigeben eines Speicherblockes,
  • 22 ist ein Flussschaubild einer Prozedur zum Zusammenführen von zusammengehörenden Blöcken,
  • 23 ist ein Flussschaubild einer Prozedur zum Entkoppeln eines Speicherblockes,
  • 24 ist ein Flussschaubild einer Prozedur zum Abfragen der Poollaufwerksblockliste,
  • 25 ist ein Flussschaubild einer Prozedur zum Abgleichen der Poollaufwerksblockliste und
  • 26 ist ein Flussschaubild einer Prozedur zum Aktualisieren der Poollaufwerksblockliste.
  • Detaillierte Beschreibung
  • I. Begriffsbestimmungen
    • „Datensatz": bezieht sich auf eine Datenansammlung mit fester Größe, die auf einer physikalischen Speichervorrichtung wie einem Laufwerksuntersystem gespeichert ist. Eine Ansammlung von Datensätzen wird als eine Datei bezeichnet.
    • „Datenübertragungsblock" („frame"): bezieht sich auf eine Austauscheinheit bei einem Seitenaustauschsystem wie ein Datensatz, der zwischen einem Speicher und einer physikalischen Speichervorrichtung wechselseitig übertragen wird.
    • „Seite": bezieht sich auf einen physikalisch adressierbaren Speicherbereich, der innerhalb des Speichers zum Abspeichern eines Datenübertragungsblockes angeordnet ist.
    • „Speicherblock": bezieht sich auf einen virtuell adressierbaren Speicherbereich innerhalb eines Datenübertragungsblockes.
    • „Laufwerksblock": bezieht sich auf einen „Speicherblock", der auf der physikalischen Speichervorrichtung liegt und nicht in dem Speicher ist.
    • „Speicherpuffer" („cache"): bezieht sich auf eine Ansammlung von Seiten identischer Größe zum Speichern von wechselweise ausgetauschten Datenübertragungsblöcken in einem Seitenaustauschsystem.
    • „Pool": bezieht sich auf ein logisches Aufteilen von Daten aufweisenden Datenübertragungsblöcken in Unterpools zum Ausbilden homogener Unteransammlungen eines Speicherbereichs.
    • „Poolseitenliste": bezieht sich auf eine Ansammlung von Seitenreferenzen, die eine doppelt verknüpfte Liste zum Verweisen auf einen sich im Speicher befindlichen Datenübertragungsblock mit einem freien Speicherblock einer vorbestimmten Größe bildet. Für jeden Speicherunterpool (nachfolgend definiert) und für jede Blockgröße gibt es eine Poolseitenliste.
    • „Poollistenkopfliste": bezieht sich auf eine Ansammlung von Seitenreferenzen in dem Speicherpuffer zum Identifizieren der Köpfe jeder Poolseitenliste.
    • „Poollaufwerksblockliste": bezieht sich auf eine Ansammlung von Zählern von teilweise zugewiesenen Datenübertragungsblöcken, die derzeit nicht in dem Speicher sind. Für jeden Speicherunter pool und für jede Blockgröße gibt es eine Poollaufwerksblockliste.
  • II. Überblick
  • Ein Ausführungsbeispiel der vorliegenden Erfindung schafft einen direkten Zugriff in konstanter Zeit auf einen freien Speicherblock des Arbeitsspeichers über Abfragen einer Poolseitenlistenkopfliste 54, wie in 5 dargestellt ist (nachfolgend detaillierter erläutert). Das Speichermanagement- und Speichersystem 1 fragt lediglich die Poolseitenlistenkopfliste 54 gemäß 5 ab, um einen Eintrag 71 zu finden, der die Nummer 72 einer Seite 46 in dem Speicher 3 speichert, die einen Datenübertragungsblock 40 (4) mit einer gewünschten Größe des Speicherblockes 45 aufweist, die wenigstens so groß wie diejenige ist, die für eine Speicheranfrage 65 (2) erforderlich ist. Falls kein Poolseitenlistenkopflisteneintrag 71 gefunden wird, der einen freien Speicherblock mit ausreichender Größe anzeigt, fragt der Speichermanager 7 eine Poollaufwerksblockliste 70 ab, um darin einen Eintrag 80 zu finden, der einen von Null verschiedenen Zähler 81 (6) speichert, der anzeigt, dass einige teilweise zugewiesene Datenübertragungsblöcke 40 auf einem Laufwerk 4 einen freien Speicherblock 45 geeigneter Größe haben. Falls kein Poollaufwerksblocklisteneintrag 71 gefunden wird, wird ein neuer Datenübertragungsblock 40 erzeugt, um die Speicheranfrage zu erledigen. Da lediglich das Kopfelement dieser Listen untersucht wird, benötigt die Abfrage eine konstante Zeitdauer und erfordert, im schlimmsten Fall, eine Überprüfung pro Speicherblockgröße (die auch ein konstantes Zeitverhalten aufweist). Bei dem erläuterten Ausführungsbeispiel gibt es beispielsweise 20 Speicherblockgrößen.
  • III. Systemkomponenten
  • Ein besonderer Typ eines Anwendungsprogramms, für das die vorliegende Erfindung besonders geeignet ist, ist ein Datenbankmanagementsystem. Datenbankdateien neigen dazu umfangreich zu sein, und daher gibt es naturgemäß einen Bedarf, die Datenübertragungsblöcke der Datenbank zwischen dem Hauptspeicher und einem Laufwerksuntersystem auszutauschen und den freien Bereich in den Datenübertragungsblöcken effizient auszunutzen, der entweder in dem Hauptspeicher oder auf dem Laufwerksuntersystem, das heißt nicht in dem Speicher, sein kann.
  • Das Speichermanagement- und Speichersystem 1 gemäß 1 verfügt über einen Hauptprozessor (CPU) 2, einen Hauptspeicher 3 und ein Laufwerksuntersystem 4, die über einen gemeinsamen Bus 5 miteinander verbunden sind. Diese Komponenten führen die üblichen Funktionen aus, die mit einem programmierten digitalen Mehrzweckcomputer zusammenhängen. Genauer gesagt führt der Hauptprozessor Anweisungen gemäß einem Computerprogramm aus. Das Laufwerksuntersystem stellt einen physikalischen Speicherbereich für durch die Anwendungsprogramme verwendete große Dateien bereit. Der Hauptspeicher speichert das Computerprogramm während der Ausführung und Dateninhalte, die von dem Laufwerksuntersystem eingelesen werden. Die Kapazität des Hauptspeichers ist merklich kleiner als die Kapazität des Laufwerksuntersystems. Übertragungen von Dateninhalten zwischen dem Hauptspeicher und dem Laufwerksuntersystem werden unter Kontrolle des Computerprogramms durch den Hauptprozessor ausgelöst, aber das tatsächliche Laden und Entladen von Dateninhalten in oder aus dem Hauptspeicher kann durch die CPU, einen Direktspeicherzugriffs-(DMA-)Controller (nicht dargestellt) oder eine ähnliche Vorrichtung hervorgerufen werden.
  • Ein typisches Beispiel eines Computersystems, das zum Verkörpern des Speichermanagementsystems der vorliegenden Erfindung geeignet ist, ist ein DEC 3000 Modell 800, hergestellt von der Digital Equipment Corporation, Maynard, MA, ausgestattet mit einem 175 Mhz EV4 CPU Chip, Teilnummer 21064, mit einem Direktzugriffsspeicher von 640 Megabytes und einem Sekundärspeicher von 10 Gigabytes.
  • IV. Speichermanagementkomponenten
  • Mit Bezug auf 2 ist der Hauptspeicher 3 in drei funktionalen Ebenen organisiert: Vektormanager (VM) 6, Speichermanager (MM) 7 und Dateimanager (FM) 8. Diese Komponenten werden zusammen mit der CPU 2 nunmehr erläutert.
  • A. Vektormanager, Dateimanager und Laufwerksuntersystem
  • Der Vektormanager 6 stellt für ein Anwendungsprogramm eine Serviceebene bereit. Bei dem erläuterten Ausführungsbeispiel ist dies ein Datenbankmanagementsystem. Es sind eine Anzahl von allgemeinen VM-Registern 9 zum Abspeichern von Informationen über Vektoren 15 in einem Speicher 3 vorhanden.
  • Ein Dateimanager 8 schafft eine datensatzbasierte Eingabe/Ausgabe-(I/O-)Schnittstelle zu dem Laufwerksuntersystem 4. Ein nach dem Last-In/First-Out-Prinzip arbeitender Stapelspeicher 10 mit freien Datensätzen wird vorgehalten, um neu zugewiesene oder freigegebene Datensätze zum Übertragen zwischen dem Hauptspeicher und dem Laufwerksuntersystem zu puffern.
  • Schließlich stellt das Laufwerksuntersystem 4 eine dauerhafte, nicht flüchtige Speicherung von Datenbankdateien 11 bereit. Die Schnittstellenbeanspruchung auf niedrigem Niveau, die erforderlich ist, um einen datensatzbasierten Zugriff auf die Datenbankdateien zu schaffen, wird durch herkömmliche Betriebssystemfunktionen in der Kernebene (Betriebssystem) geschaffen.
  • Innerhalb des Hauptspeichers 3 sind sowohl der Vektormanager 6 als auch der Dateimanager 8 über Schnittstellen mit dem Speichermanager 7 verbunden. Der Vektormanager 6 und der Speichermanager 7 tauschen Speicherblockanfragen 65 aus. Eine Speicherblockanfrage (65, 2) wird über den Vektormanager 6 ausgegeben, um einen gewünschten Umfang an zuzuweisenden freien Speicher zu identifizieren, um Daten in Bytes zu speichern. Der Speichermanager 7 und der Dateimanager 8 tauschen Datensatzanfragen aus. Es gibt vier Arten von Datensatzanfragen: readrec(), writerec(), newrec() und freerec(). Die letzten beiden Datensatzanfragen fordern eine Schnittstelle mit dem Stapelspeicher mit freiem Speicher an. Der Dateimanager 8 und das Laufwerksuntersystem 4 tauschen I/O-Anfragen aus. Es gibt drei Arten von I/O-Anfragen: read(), write(), und seek().
  • B. Speichermanager
  • Der Speichermanager 7 verwaltet Speicherblockanfragen 65 nach Speicherblöcken variabler Größe, die von dem Vektormanager erhalten werden, und Datensatzanfragen für Datensatzübertragungen mit fester Größe von dem Dateimanager 8. Die den Speichermanager 7 bildenden Komponenten werden am besten durch einleitendes Beschreiben des gesamten Speicherorganisationsschemas verstanden.
  • 1. Speicherorganisationsschema
  • Mit Bezug auf 4 ist jede Datenbankdatei, die in dem Laufwerksuntersystem gespeichert ist, in einzelne, gleich dimensionierte Daten beinhaltende Datenübertragungsblöcke 40 aufgeteilt, die beispielsweise aus 8 Megabytes (MB) Daten bestehen. Eine Datenbankdatei 41, die einen Konfigurationsdatensatz („Config") 42, Kopfdatenübertragungsblöcke 43 (nachfolgend weiter erläutert) und Daten aufweisende Datenübertragungsblöcke 40 aufweist, ist in 4 dargestellt. Ausgetauschte Datenübertragungsblöcke werden in dem Speicherpuffer 15 des Speichers 3 gespeichert. Der Speicherpuffer ist beispielsweise in eine Anzahl von nummerierten Seiten 47 aufgeteilt, wobei jede Seite ebenfalls 8 MB groß ist. Es gibt wesentlich mehr Datenübertragungsblöcke 40 in der Datenbankdatei auf dem Laufwerksuntersystem 4 als Seiten in dem Speicherpuffer 15.
  • Jeder einzelne Datenübertragungsblock 40 kann freien Speicherbereich aufweisen, in dem keine Daten abgespeichert sind und der durch ein Anwendungsprogramm zum Speichern von Daten verwendet werden kann, sobald der Daten aufweisende Datenübertragungsblock in eine Seite des Speicherpuffers 15 geladen wird. Mit Bezug auf 3 ist jeder Datenübertragungsblock in proportionale, gleich große Speicherblöcke 45 in 3 unterteilt. Jeder Speicherblock 45 hat eine Größe, die bei dem erläuterten Ausführungsbeispiel eine Potenz von 2 ist. Es sind 20 Blockgrößen verfügbar, die in der Größe zwischen 16 Bytes bis 8 Megabytes liegen. Der kleinste Speicherblock mit 16 Bytes ist als ein zusammenhängender Speicherabschnitt („paragraph") bekannt, und die Speicherblöcke liegen im Bereich von 1 bis 512 K Speicherabschnitten potenziert mit 2.
  • Die Blockgrößen, Bytes und Speicherabschnitte bei dem erläuterten Ausführungsbeispiel sind zu Zwecken eines einfacheren Verständnisses in Tabelle 1 zusammengefasst. Speicherblöcke 15 werden nur an einem dieser vorbestimmten Blockgrößen zur Verwendung durch den Vektormanager 6 dynamisch zugewiesen. Ein Speicherüberschuss wird verschwendet, wenn die zugewiesene Speicherblockgröße größer als die nachgefragte Größe ist. Die Struktur des Speichermanagers 7 wird nun erläutert.
  • 2. Speichermanagerstruktur
  • Datenstrukturen in der Sprache C für die Komponenten, die das erläuterte Ausführungsbeispiel der vorliegenden Erfindung umfasst, sind in 8 bis 13 dargestellt.
  • a. Seiten
  • Mit Bezug auf 2 und 5 kann jede Seite 46 innerhalb des Speicherpuffers 15 zum Speichern eines Daten aufweisenden Datenübertragungsblockes 45 oder eines Kopfdatenübertragungsblockes 43 verwendet werden, die von den Laufwerksuntersystem 4 über den Dateimanager 8 hereingenommen werden. Jede Seite 46 (oder Seite 13) ist durch eine Seitennummer 47 identifiziert. Bei dem erläuterten Ausführungsbeispiel hat der Speicherpuffer 232 Seiten, und die Seitennummern bewegen sich entsprechend zwischen 0 bis 232 – 1.
  • Eine Datenstruktur für ein Speicherpuffersteuerfeldelement für eine Seite ist in 8 dargestellt. Die 232 Elemente der Speicherpuffersteuerdaten 15 sind als ein Feld 13 mit dem Namen „cache_page⫿" gespeichert. Mit Bezug auf 5 und 8 beinhaltet jedes Speicherpuffersteuerfeldelement fünf Datenfelder. Ein Zeiger p_data 48 speichert eine Adresse für den Datenbereich der Seite. Die Datenübertragungsblocknummer des Datenübertragungsblockes in jeder Seite ist in pframe 49 gespeichert. Die einzelnen Feldelemente sind weiterhin innerhalb einer doppelt verknüpften Liste unter Verwendung einer Verknüpfung zu der nächsten Seite pnext 50 und der vorangehenden Seite pprev 51 in dem Speicherpuffer verknüpft. Schließlich ist für jedes Paar von Verknüpfungen ppl für die nächste Seite 52 und die vorangehende Seite 53 in der nachfolgend erläuterten pplheads-Liste 54 für jede einzelne Blockgröße gespeichert. Eine Datenstruktur für die ppl ist in 9 dargestellt. Es ist die ppl-Datenstruktur, die das zeitlich konstante Zuweisverhalten hervorruft.
  • b. Datenübertragungsblöcke
  • Der MEMCONFIG/MEMDATA-Abschnitt 12 („MEMCONFIG") des Speichers 3 (2) wird verwendet, um Informationen über die Datenübertragungsblöcke 40 und deren freien Speicherblöcke 45 zu speichern. Die Information über alle Datenübertragungsblöcke wird durch MEMCONFIG über die Verwendung eines Feldes von Laufwerkspositionen für alle Kopfdatenübertragungsblöcke verfügbar gemacht, wodurch Zugriff auf alle Datensatzübertragungsköpfe geschaffen ist. Eine Datenstruktur, die ein Datenübertragungsblockkopfelement beschreibt, ist in 10 dargestellt und umfasst fünf Datenfelder.
  • Mit Bezug auf 3 und 10 zeigt zunächst eine Verfügbarkeitsbitfolge availmap 60 an, ob ein Speicherblock einer spezifizierten Blockgröße in dem entsprechenden Datenübertragungsblock durch Verwendung eines speziellen Bits frei ist. Innerhalb availmap 60 gibt es eine Bitposition, die jeweils einer der Blockgrößen entspricht. Die einzelnen Bitpositionen werden zum Erleichtern des Verständnisses in der Tabelle 2 zusammengefasst. Beispielsweise ist availmap 32 Bit lang, und die Bitpositionen liegen von der Bitposition 4 (entsprechend der Blockgröße 1) bis 23 (entsprechend der Blockgröße 20). Die Verfügbarkeitsbitfolge in availmap für jede Blockgröße und die entsprechenden Bitpositio nen sind zum einfacheren Verständnis in der Tabelle 1 zusammengefasst. Nicht verfügbare Größen sind in availmap durch ein 0-Bit angezeigt. Falls der Datenübertragungsblock freie Speicherblöcke verschiedener Größe aufweist, werden die Verfügbarkeitsbits addiert. Mit Bezug auf 3 hat beispielsweise der Datenübertragungsblock 6 freie Speicherblöcke der Größen 1 und 4–6. Die Verfügbarkeitsbitmasken dieser Blockgrößen (aus Tabelle 1) führen zu einer Verfügbarkeitsbitfolge, die wie folgt berechnet wird:
    Blockgröße 1: 0×00000010
    Blockgröße 4: 0×00000080
    Blockgröße 5: 0×00000100
    Blockgröße 6: + 0×00000200
    availmap 0×00000390
  • Mit Bezug auf 3 und 10 hat weiterhin jeder Datenübertragungsblockkopf eine Blockversatzliste boffs[] 62, die, wie wiederum in 10 dargestellt ist, nach der Blockgröße organisiert ist. Jeder Blockversatzeintrag zeigt die relative Anordnung des ersten freien Speicherblockes einer ausgewählten Blockgröße innerhalb des Datenübertragungsblockes an. Weitere freie Speicherblöcke einer gegebenen Blockgröße werden dann über den nachfolgend erläuterten Speicherblockkopf verknüpft. Da ein Speicherblock der maximalen Blockgröße den gesamten Datenübertragungsblock einnimmt, ist es nicht erforderlich, innerhalb der Blockversatzliste für einen maximal dimensionierten Speicherblock einen Versatz beizubehalten.
  • Drei Beispiele von Datenübertragungsblöcken und deren Verfügbarkeitsbitfolgen sowie Blockversatzlisten sind in 3 dargestellt. Aus Gründen der Klarheit sind lediglich der erste freie Speicherblock jeder Blockgröße und die ersten 4096 Bytes jedes Datenübertragungsblockes dargestellt, auch wenn jeder Datenübertragungsblock mehr als einen Speicherblock von jeder Grö ße aufweisen kann und bei dem erläuterten Ausführungsbeispiel 8 MB ist. Der Datenübertragungsblock 3 hat eine Verfügbarkeitsbitfolge von 0×000007D0. Mit Bezug auf Tabelle 1 zeigt diese Verfügbarkeitsbitfolge an, dass der Datenübertragungsblock 3 freie Speicherblöcke der Größen 1 und 3–7 hat. Entsprechend zeigen die Verfügbarkeitsbitfolgen der Datenübertragungsblöcke 6 und 7, die jeweils 0×00000390 und 0×00000810 sind, an, dass diese Datenübertragungsblöcke freie Speicherblöcke jeweils der Größen 1, 4–6 beziehungsweise 1 sowie 8 aufweisen. Der Datenübertragungsblock 3 hat eine Blockversatzliste, die angibt, dass der erste freie Speicherblock der Größe 1 einen relativen Versatz von 0×00000740 hat. Entsprechend haben die ersten freien Speicherblöcke der Größen 3 bis 7 jeweils einen Versatz von 0×00000840, 0×00000880, 0×00000900, 0×00000A00 und 0×00000C00. Die Blockversatzlisten der Datenübertragungsblöcke 6 und 7 werden entsprechend interpretiert.
  • Schließlich hat jedes Datenübertragungsblockkopfelement drei weitere Dateninhalte. Der Speicherbereich, der bei dem erläuterten Ausführungsbeispiel durch das Anwendungsprogramm verwendet wird, ist logisch in homogene Ansammlungen von Speicherbereichen aufgeteilt, die als Pools bekannt sind. Jeder Datenübertragungsblockkopf enthält eine Nummer eines Pools pool, die den Speicherunterpool des Datenübertragungsblockes identifiziert. Schließlich hat jeder Datenübertragungsblock zwei Zeiger fnext und fprev, die eine doppelt verknüpfte Liste bilden, die jeweils auf den nächsten und den vorangegangenen Datenübertragungsblock zeigen, die in dem zugewiesenen Speicherunterpool angeordnet sind.
  • c. Speicherblöcke
  • Jeder Datenübertragungsblock besteht aus einem Satz von Speicherblöcken 45, der beispielsweise eine Speichereinheit ist, deren Größen in Bytes genaue Potenzen von 2 sind. Der kleinste Speicherblock hat 16 Bytes und ist als zusammenhängender Speicherabschnitt bekannt. Der größte Speicherblock ist 8 MB oder der gesamte Datenübertragungsblock. Wie in Tabelle 1 dargestellt gibt es 20 Blockgrößen. Die Anzahl an Bytes n, die in jeder Blockgröße gespeichert ist, ist durch die Gleichung n = 2<blksiz> + 3 definiert, wobei <blksiz> die Blockgröße des Speicherblockes ist.
  • Jeder freie Speicherblock innerhalb eines Datenübertragungsblockes hat einen Blockkopf. Eine Datenstruktur für einen Speicherblockkopf ist in 11 dargestellt. Er umfasst fünf Dateninhalte. Die Blockköpfe sind innerhalb einer doppelt verknüpften Liste mit einer Liste für jede unterschiedliche Speicherblockgröße organisiert. Die p_succlink- und p_predlink-Variablen speichern die Versätze jeweils zu den Nachfolger- und Vorgängerspeicherblöcken mit freiem Speicher einer gegebenen Blockgröße. Ein Datenübertragungsblock kann mehrere freie Speicherblöcke der gleichen Blockgröße aufweisen, und daher sind Blockköpfe für gleich große Speicherblöcke, die innerhalb des gleichen Speicherblockes angeordnet sind, innerhalb der doppelt verknüpften Listen gebildet. Diese doppelt verknüpften Listen sind in der Blockversatzliste boffs⫿ in dem Übertragungsblockkopf vorangestellt. In Datenübertragungsblock kann es eine verknüpfte Liste von freien Speicherblöcken für jede unterschiedliche Speicherblockgröße geben. Falls umgekehrt für eine bestimmte Blockgröße keine freien Speicherblöcke vorhanden sind, dann wird es keine entsprechende verknüpfte Liste geben, da der boffs⫿-Eintrag leer sein wird. Jeder Speicherblockkopf enthält weiterhin eine Marke f_availtag, die anzeigt, dass der Speicherblock frei ist, und eine Blockgröße kval8, die für einen bestimmten Speicherblock die Potenz von 2 der Blockgröße angibt.
  • d. Poolseitenlistenkopfliste
  • Die Poolseitenlistenkopfliste („pplheads-Liste") 14 beinhaltet die Köpfe der zweifach verknüpften Poolseitenlisten, die über die ppl-Felder in das Speicherpuffersteuerfeld cache_page⫿ (in 8 dargestellt) eingeführt sind. Die pplheads-Liste ist entsprechend der Blockgröße organisiert. Eine Datenstruktur für eine pplheads-Liste ist in 12 dargestellt. Wie bei der Blockversatzliste, die innerhalb jedes Datenübertragungsblockkopfes gespeichert ist (siehe 10), ist es nicht erforderlich, in der pplheads-Liste für die maximale Speicherblockgröße einen Eintrag zu haben, da diese Speicherblockgröße den Gesamtdatenübertragungsblock in Anspruch nimmt.
  • Wie weiter unten näher erläutert ist, verschafft die pplheads-Liste dem Speichermanager einen Zugriff mit konstanter Zeit auf eine Seite, die einen Datenübertragungsblock aufweist, der einen freien Speicherblock einer vorbestimmten Blockgröße hat. Beispielsweise enthält der siebte Eintrag (entsprechend der Blockgröße 7) der pplheads-Liste pplheads[7] (in 5 dargestellt) 34 (entsprechend der durch die Seitennummer 34 indizierten Seite), was angibt, dass in dem Datenübertragungsblock 3 ein freier Speicherblock der Blockgröße 7 vorhanden ist.
  • e. Kopftabellenliste
  • Die Poollaufwerksblockliste („pdb-Liste") 70 ist in MEMCONFIG gespeichert. Eine die pdb-Liste beschreibende Datenstruktur ist in 13 dargestellt. Jedes Element der pdb-Liste beinhaltet einen Zähler der teilweise zugewiesenen Datenübertragungsblöcke auf dem Laufwerksuntersystem, die freie Speicherblöcke mit einer gegebenen Blockgröße aufweisen. Wie weiter unten weiter erläutert ist, wird die pdb-Liste durch den Speichermanager un tersucht, wann immer ein freier Speicherblock in dem Datenübertragungsblock nicht gefunden werden kann, der aktuell in dem Speicherpuffer vorhanden ist.
  • f. Poolkopfliste
  • Jeder Speicherunterpool verfügt über eine zweifach verknüpfte Liste von Datenübertragungsköpfen. Die Köpfe jeder dieser Listen werden in den Poolkopflisten („poolheads-Liste") gesammelt, die in MEMCONFIG gespeichert ist.
  • g. Kopftabellenliste
  • Die Datenübertragungsblockköpfe werden in Datenübertragungsblöcken gesammelt, die als Datensätze in der Datenbankdatei gespeichert sind. Diese Sammlungen von Datenübertragungsblockköpfen werden Kopfdatenübertragungsblöcke genannt, und ihre Laufwerkspositionen werden in der Kopftabellenliste („hdrtable-Liste") abgelegt, die in MEMCONFIG gespeichert ist. Ein Zugriff auf die Datenübertragungskopflaufwerkspositionen in der hdrtable-Liste ist unter Benutzen der Kopfdatenübertragungsblocknummer des Kopfes als Index gewährleistet.
  • VI. Organisieren eines Speichermanagementsystems
  • Ein Flussschaubild, das die Schritte zusammenfasst, die erforderlich sind, um ein Speichermanagementsystem gemäß der vorliegenden Erfindung zu organisieren, ist in 7 dargestellt. Als erstes wird der Speicher in eine Vielzahl von nummerierten Seiten partitioniert, um einen Speicherpuffer zum Speichern von ausgelagerten Datenübertragungsblöcken (Block 51) zu bilden. Eine Poolseitenkopfliste, die bei dem erläuterten Ausführungs beispiel als pplheads-Liste bezeichnet ist, wird zum Lokalisieren von freien Speicherblöcken in Datenübertragungsblöcken beibehalten, die in Seiten liegen, wobei sie nach der Blockgröße organisiert ist (Block 52). Eine Laufwerksblockliste, die bei dem erläuterten Ausführungsbeispiel als pdb-Liste bezeichnet ist, wird zum Beibehalten eines Zählers von freien Speicherblöcken einer vorgegebenen Blockgröße, die in Datenübertragungsblöcken auf dem Laufwerksuntersystem (das heißt in Datenübertragungsblöcken, die sich derzeit nicht im Speicherpuffer befinden) beibehalten (Block 52). Eine Seitennummer, die in jedem Eintrag der Poolseitenliste gespeichert ist, wird in Abhängigkeit einer Speicheranfrage von einem Anwendungsprogramm nachgeschlagen (Block 54), wobei die Seitennummer einer Seite in dem Speicherpuffer entspricht, die einen Datenübertragungsblock beinhaltet, der einen freien Speicherblock einer der vorbestimmten Blockgrößen aufweist. Schließlich wird für den Speicherblock in Bezug auf den Beginn der Seite eine Adresse berechnet (Block 55), die an das Anwendungsprogramm zurückgegeben wird, um die Speicheranfrage zu erledigen.
  • Bei dem erläuterten Ausführungsbeispiel wird eine Datenbankdatei in dem Laufwerksuntersystem vor und nach einer Programmausführung eingebunden beziehungsweise ausgegliedert. Während eines Einbindevorganges wird eine dauerhafte Kopie der pdb-Liste von einem Datenbankkonfigurationsdatensatz auf dem Laufwerksuntersystem in den Speicher kopiert. Weiterhin werden eine dauerhafte Kopie der poolheads- und hdrtable-Listen von dem Datenbankkonfigurationsdatensatz in MEMCONFIG kopiert. Weiterhin wird die pplheads-Liste auf Null initialisiert. Während Auslagerungsoperationen werden die pplheads- und pdb-Listen von dem Speichermanager in dem Umfang aktualisiert, wie Datenübertragungsblöcke in den Speicherpuffer hinein und aus diesem heraus übertragen werden. Der Betrieb des Speichermanagers wird nachfolgend erläutert.
  • V. Beispiele für eine Speicherblockzuweisung
  • Beispiel 1
  • Es sei angenommen, dass ein Anwendungsprogramm einen Speicherblock von 100 Bytes anfordert. Mit Bezug auf Tabelle 1 ist die kleinste Blockgröße, die die Speicheranfrage erfüllt, die Größe 4, die 128 Bytes oder acht 16-Byte-Speicherabschnitte enthält. Der Speichermanager versucht zunächst, die Speicheranfrage durch Lokalisieren eines Speicherblockes der Blockgröße 4 in einem in dem Speicherpuffer befindlichen Datenübertragungsblock durch Abfragen der pplheads-Liste zu erledigen. Mit Bezug auf 5 ist das vierte Element (entspricht der Blockgröße 4) der pplheads-Liste (pplheads[4]) gleich 23, was anzeigt, dass die Speicherpuffer-Seite 23 (cache_page[23]) einen freien Speicherblock der Blockgröße 4 in dem Datenübertragungsblock 6 (pframe: 6) enthält. Mit Bezug auf 3 enthält das vierte Element (entspricht einer Blockgröße 4) des Blockversatzfeldes (boffs[4]) den Versatz (0×0000 0080) des freien Speicherblockes 30 der Blockgröße 4. Die Speicheranfrage ist d5rch Rückgabe der Datenübertragungsnummer (6), der Seitennummer (23) und des Versatzes (0×00000080) an das anfordernde Anwendungsprogramm erledigt.
  • Beispiel 2
  • Es sei angenommen, dass ein Anwendungsprogramm einen Speicherblock von 2.000 Bytes anfordert. Mit Bezug auf Tabelle 1 ist die kleinste Blockgröße, die die Speicheranfrage erfüllt, die Größe 8, die 2.048 Bytes oder 128 16-Byte-Speicherabschnitte enthält. Der Speichermanager versucht zunächst, die Speicheranfrage durch Lokalisieren eines Speicherblockes der Blockgröße 8 in einem in dem Speicherpuffer befindlichen Datenübertra gungsblock zu erledigen. Mit Bezug auf 6 ist das achte Element (entspricht der Blockgröße 8) der pplheads-Liste (pplheads[8]) gleich Null (00), was anzeigt, dass keiner der Datenübertragungsblöcke in dem Speicherpuffer einen freien Speicherblock der Blockgröße 8 hat. Der Speichermanager fährt fort, die pplheads-Liste für jede nachfolgende größere Blockgröße abzufragen, bis die Liste erschöpft ist. Bei diesem Beispiel gibt es keine freien Speicherblöcke der Blockgröße 8 oder größer, die in irgendeinem in dem Speicherpuffer befindlichen Speicherblock lokalisiert ist.
  • Als nächstes versucht der Speichermanager, die Speicheranfrage durch Lokalisieren eines Speicherblockes der Blockgröße 8 in einem teilweise zugewiesenen Datenübertragungsblock zu erledigen, der in dem Laufwerksuntersystem liegt, indem die pdb-Liste abgefragt wird. Mit Bezug wiederum auf 6 ist das achte Element (entspricht der Blockgröße 8) der pdb-Liste (pdb[8]) gleich 1, was ein Zählereintrag ist, der anzeigt, dass es genau einen in dem Laufwerksuntersystem liegenden, teilweise zugewiesenen Datenübertragungsblock gibt, der einen freien Speicherblock der Blockgröße 8 enthält.
  • Schließlich untersucht der Speichermanager die poolheads-Liste (die, wie in 2 dargestellt ist, in MEMCONFIG gespeichert ist) des aktuellen Speicherunterpools, um den Kopf der zweifach verknüpften Speicherblockkopfliste zu finden. Sobald der Listenkopf erhalten wurde, untersucht der Speichermanager die Verfügbarkeitsbitfolge (availmap) für jeden Datenübertragungsblockkopf in der zweifach verknüpften Datenübertragungsblockkopfliste, bis der Datenübertragungsblock, der den freien Speicherblock der Größe 8 enthält, gefunden ist. Mit Bezug auf 3 haben weder die Verfügbarkeitsbitfolgen der Datenübertragungsblockköpfe der Datenübertragungsblöcke 3 und 6 (0×000007D0 beziehungsweise 0×00000390) ein Verfügbarkeitsbit (in Tabelle 1 dargestellt) für eine Blockgröße 8 (0××00000800) gesetzt. Demnach haben weder die Datenübertragungsblöcke 3 oder 6 einen freien Speicherblock der Blockgröße 8. Die Verfügbarkeitsbitfolge des Datenübertragungsblockkopfes des Datenübertragungsblockes 7 (0×00000810) hat jedoch ein Verfügbarkeitsbit für die Blockgröße 8 gesetzt. Das achte Element (entspricht der Blockgröße 8) des Blockversatzfeldes (boffs[8]) enthält den Versatz (0×00000800) des freien Speicherblockes 31 der Blockgröße 8. Die Speicheranfrage ist durch Rückgabe der Datenübertragungsblocknummer (7), der Seitenzahl (00) und des Versatzes (0×00000800) an das anfragende Anwendungsprogramm erledigt.
  • Beispiel 3
  • Es sei angenommen, dass ein Anwendungsprogramm einen Speicherblock von 8.000 Bytes anfordert. Mit Bezug auf Tabelle 1 ist die kleinste Blockgröße, die die Speicheranfrage erfüllt, die Größe 10, die 8.192 Bytes oder 512 16-Byte-Speicherabschnitte enthält. Der Speichermanager versucht zunächst, die Speicheranfrage durch Lokalisieren eines Speicherblockes der Blockgröße 10 in einem in dem Speicherpuffer befindlichen Datenübertragungsblock zu erledigen. Mit Bezug auf 6 ist das zehnte Element (entspricht der Blockgröße 10) der pplheads-Liste (pplheads[10]) gleich Null (00), was anzeigt, dass keiner der Datenübertragungsblöcke in dem Speicherpuffer einen freien Speicherblock der Blockgröße 10 hat. Der Speichermanager fährt fort, die pplheads-Liste für jede nachfolgende größere Blockgröße abzufragen, bis die Liste erschöpft ist. Bei diesem Beispiel gibt es keine freien Speicherblöcke der Blockgröße 10 oder größer, die in irgendeinem in dem Speicherpuffer befindlichen Speicherblock lokalisiert ist.
  • Als nächstes versucht der Speichermanager, die Speicheranfrage durch Lokalisieren eines Speicherblockes der Blockgröße 10 in einem teilweise zugewiesenen Datenübertragungsblock zu erledigen, der in dem Laufwerksuntersystem liegt, indem die pdb-Liste abgefragt wird. Mit Bezug wiederum auf 6 ist das zehnte Element (entspricht der Blockgröße 10) der pdb-Liste (pdb[10]) gleich Null (0), was ein Zählereintrag ist, der anzeigt, dass es keine teilweise zugewiesenen Datenübertragungsblöcke gibt, die auf dem Laufwerksuntersystem liegen, die einen freien Speicherblock der Blockgröße 10 beinhalten. Der Speichermanager fährt fort, die pdb-Liste für jede nachfolgende größere Blockgröße abzufragen, bis die Liste erschöpft ist. Bei diesem Beispiel gibt es keine freien Speicherblöcke der Blockgröße 10 oder größer, die in einem auf dem Laufwerksuntersystem liegenden, teilweise zugewiesenen Datenübertragungsblock lokalisiert sind. Da somit kein Speicherblock einer ausreichenden Größe gefunden worden ist, wird ein neuer Datenübertragungsblock erzeugt, um die Speicheranfrage zu erledigen.
  • VI. Struktur des Speichermanagerprogramms
  • Die Programmstruktur des Speichermanagers gemäß der vorliegenden Erfindung ist schematisch in den Flussschaubildern von 14–25 dargestellt. Gemäß Konvention der Sprache C werden Vorprozessormakros oder Konstanten durchgehend in Großbuchstaben geschrieben, und Programmvariablen erscheinen durchgehend in Kleinbuchstaben. Eine Zusammenfassung der Makrodefinitionen ist für ein einfaches Verständnis in Tabelle 3 gegeben, worin der Makroname, sein Wert und eine kurze Beschreibung angegeben ist. Entsprechend ist eine Zusammenfassung der Flussschaubilder von 14–26 für ein einfaches Verständnis in den Tabellen 4A–D gegeben, wobei der Name des Flussschaubilds eine kurze Beschreibung des Verfahrens sowie dessen Eingaben, Variablen und Ausgaben angegeben ist. Jeder dieser Abläufe wird nun mit Bezug auf Tabelle 3 und 4 beschrieben.
  • Das Verfahren zum Auffinden und Zuweisen eines Speicherblockes 45 in Abhängigkeit einer Speicheranfrage 65 ist in 14 dargestellt. Es ist dessen Zweck, die erforderliche Anzahl von Speicherblöcken 45 zu erhalten, die erforderlich sind, um eine Speicheranfrage 65 (2) für eine variable Anzahl von Bytes zu erledigen. Falls die nachgefragte Anzahl von zuzuweisenden Bytes reqsize größer oder gleich der maximalen Anzahl von Bytes MAX_BYTES (Tabelle 3) ist, wird in einem Datenübertragungsblock 40 (Block 100) die Blockgröße supply des zugewiesenen Speicherblockes 45 auf Null gesetzt (Block 101). Eine Null zeigt an, dass ein neuer Datenübertragungsblock 40 erforderlich ist (Block 102), um die Speicheranfrage 65 zu erledigen. Falls andererseits die erforderliche Anzahl von zuzuweisenden Bytes kleiner als die maximale Anzahl von Bytes in einem Datenübertragungsblock ist, wird eine Blockgröße (reqsize) in demand (Block 105) für die kleinste zum Erledigen der Anfrage erforderliche Blockgröße gespeichert. Die pplheads-Liste 54 wird abgefragt (Block 106), wie weiter unten zu 15 beschrieben wird. Falls die Abfrage der pplheads-Liste nicht zum Auffinden eines freien Speicherblockes 45 wenigstens von der Größe wie demand führt, wird eine auf Null gesetzte Datenübertragungsblocknummer 49 in frame (Block 107) gesetzt, was anzeigt, dass die pdb-Liste 70 abgefragt werden muss (Block 108), wie nachfolgend bei 24 beschrieben wird. Falls die Abfrage der pdb-Liste 70 zu keinem Auffinden eines freien Speicherblockes 45 von wenigstens einer demand entsprechenden Größe führt, bleibt die Datenübertragungsblocknummer 49 bei Null (Block 109) und zeigt an, dass ein neuer Datenübertragungsblock 40 erzeugt werden muss (Block 102). Falls die Abfrage der pdb-Liste erfolgreich war, muss der Datenübertragungsblock, der in der Abfrage der pdb-Liste lokalisiert worden ist (in Block 108), erzeugt oder von dem Laufwerksuntersystem 4 (Block 110) gelesen werden. Sobald ein neuer Datenübertragungsblock lokalisiert oder ein vorhandener Datenübertragungsblock erzeugt worden ist, wird ein Speicherblock 45 von der diesen Datenübertragungsblock 40 aufweisenden Seite 46 zugewiesen (Block 103), wie weiter unten bei 16 beschrieben wird. Die Prozedur gibt die Datenübertragungsblockzahl 49, die Seitenzahl 47 und den Versatz 67 des Speicherblockes 45 innerhalb des Datenübertragungsblockes 45 zurück (Block 104).
  • Ein Verfahren zum Abfragen der pplheads-Liste 54 (Block 106), das auf den obigen Einflussgrößen beruht, ist in 15 dargestellt. Dessen Zweck ist das Abfragen der pplheads-Liste 54 auf einen Speicherblock 45 einer gewünschten Blockgröße. Die kleinste zuzuweisende Blockgröße ist durch Speichern von demand in i ausgewählt (Block 120). Jeder pplheads-Listenseiteneintrag 71 wird durch Blockgröße überprüft (Block 121). Zu diesem Zweck wird die Indexnummer für jeden ppl-Kopflisteneintrag 71 in pi gespeichert. Jeder Seiteneintrag 71 wird untersucht, um zu bestimmen, ob er Null ist oder die Nummer einer Seite 47 in dem Speicherpuffer 15 speichert, die einen Datenübertragungsblock beinhaltet, der die gewünschte Speicherblockgröße hat (Block 122). Falls dies nicht der Fall ist, das heißt, wenn der Seiteneintrag 71 gleich Null ist, wird die Blockgröße um Eins hochgezählt (Block 123), und der Vorgang wird wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 124). Falls ein Seiteneintrag 71, der anzeigt, dass ein geeigneter Speicherblock 45 existiert, in dem Block 122 gefunden worden ist, werden die Blockgröße i des ausgewählten Speicherblockes 45 und der Seiteneintrag 71 pi (Block 125) sowie die Datenübertragungsblocknummer pframe 49 jeweils in frame, in supply und in page gespeichert (Block 126). Falls andererseits in Block 124 die maximale Blockgröße überschritten worden ist, werden die Blockgröße supply und die Seitennummer 47 (Block 127) sowie die Datenübertragungsblocknummer 49 (Block 120) auf Null gesetzt. Die Blockgröße supply, die Datenübertragungsblocknummer 49 und die Seiten nummer 47 werden an die aufrufende Routine zurückgegeben (Block 129).
  • Ein Flussschaubild einer Prozedur zum Zuweisen eines Speicherblockes 45 (Block 103), der auf den obigen Einflussgrößen beruht, ist in 16 dargestellt. Es ist dessen Zweck, einen Speicherblock 45 einer ausgewählten Blockgröße auf der spezifischen Seite 46 in dem Speicherpuffer 15 zuzuweisen. Das availmap des zuvor ausgewählten Datenübertragungsblockkopfes (10) FHDR wird in der Programmvariablen oldavail gespeichert (Block 140). Falls die Blockgröße supply Null ist (Block 141), was anzeigt, dass kein geeigneter Speicherblock 45 lokalisiert werden konnte, wird die Blockgröße supply auf die in dem Eingangsparameter demand gespeicherte Blockgröße gesetzt (Block 142), und size wird auf die tatsächliche Anzahl von Bytes BYTES(supply) für die Blockgröße supply der ursprünglichen Anfrage gesetzt (Block 143). Die Verfügbarkeitsbitfolge 60 des ausgewählten Datenübertragungsblockes oldavail und die gewünschte Anzahl von zuzuweisenden Bytes size werden logisch mit UND verknüpft (Block 144), und falls dieses Ergebnis Null ist, wird die Blockgröße supply hochgezählt (Block 146). Der Ablauf (Blöcke 143, 144, 146) wird wiederholt, bis entweder die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 147) oder bis ein passender Speicherblock 45 gefunden worden ist (Block 144). Sobald ein Speicherblock 45, der wenigstens so groß ist wie die gewünschte Größe, innerhalb des Datenübertragungsblockes lokalisiert worden ist (Block 144), wird der Blockversatz 67 des Speicherblockes boffs[supply] in der Programmvariablen offset gespeichert (Block 145), und das Blockversatzfeld 62 boffs⫿ und der Blockkopf (11) BHDR werden aktualisiert (Block 149), wie weiter unten bei 17 erläutert ist. Falls die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) erreicht worden ist (Block 147), wird der Versatz 67 des Speicherblockes 45 offset auf Null gesetzt (Block 148), da die Speicherblockgröße gleich der des gesamten Datenübertragungsblo ckes ist. Die Anzahl der zugewiesenen Bytes (nachgefragte Blockgröße wie erforderlich) BYTES(demand) wird in der Programmvariablen size (Block 150) gespeichert und von der Verfügbarkeitsbitfolge 60 availmap abgezogen (Block 151).
  • Die nachfolgende Prozedur führt verschiedene Datenpflegeaufgaben durch. Der Blockkopf (11) BHDR wird an dem Versatz 67 des ausgewählten Speicherblockes 45 offset untersucht (Block 152), und der Zeiger auf den nachfolgenden Speicherblock 45 p_succlink des Blockkopfes (11) BHDR wird in der Programmvariablen succ gespeichert (Block 153). Falls der Zeiger auf den Nachfolgespeicherblock 45 succ von Null verschieden ist, was anzeigt, dass ein weiterer Block in dem Datenübertragungsblock einen freien Speicherblock 45 der gleichen ausgewählten Größe hat (Block 154), wird der Zeiger auf den Vorgängerspeicherblock 45 p_predlink des Nachfolgerspeicherblockes 45 auf Null gesetzt (Block 155), das heißt, der Speicherblockkopf (11) für den Block in dem Datenübertragungsblock wird so gesetzt, dass er nicht mehr auf den aktuellen Block zurück verweist. Die Anzahl der zugewiesenen Bytes size wird aus der Größe des Speicherblockes 45, der zugewiesen worden ist (BYTES(supply)), bestimmt (Block 156) und zu der Verfügbarkeitsbitfolge 60 availmap des Datenübertragungsblockes hinzugezählt (Block 157). Unabhängig davon, ob ein Versatz 67 zu einem Nachfolgerspeicherblock 45 vorhanden ist, wird der Blockversatzfeldeintrag boffs[supply] aktualisiert, um auf den nachfolgenden freien Speicherblock 45 succ des ausgewählten Speicherblockes zu verweisen (Block 158). Schließlich wird die aktuelle Verfügbarkeitsbitfolge 60 availmap für den ausgewählten Datenübertragungsblock mit der ursprünglichen Verfügbarkeitsbitfolge 60 oldavail verglichen (Block 159), und der ppl für den ausgewählten Speicherunterpool pool werden angepasst (Block 160), wie weiter unten in 18 erläutert ist. Nachdem der ppl angepasst worden ist oder falls die Verfügbarkeitsbitfolgen 60 nicht zusammenpassen (Block 159), wird der Versatz 67 des ausgewählten Speicherblockes 45 offset an die aufrufende Prozedur zurückgegeben (Block 161).
  • Eine Prozedur zum Aktualisieren eines Blockversatzfeldes 62 und eines Blockkopfes (11) (Block 149), die auf den obigen Einflussgrößen beruhen, ist in 17 dargestellt. Deren Zweck ist es, ein Blockversatzfeld 62 und einen Blockkopf (11) zu aktualisieren. Eine zuzuweisende kleinste Blockgröße demand wird in der Programmvariablen kval gespeichert (Block 170). Die Anzahl der Bytes in der aktuellen, zu aktualisierenden Blockgröße BYTES(kval) wird in der Programmvariablen size gespeichert (Block 171). Der Eintrag in dem Blockversatzfeld 62, der der ausgewählten Blockgröße boffs[kval] entspricht, wird auf die Summe des Versatzes 67 zu dem zugewiesenen Speicherblock 45 offset zuzüglich der Anzahl von Bytes in der aktuellen, zu aktualisierenden Blockgröße size gesetzt (Block 172). Der Blockkopf (11) BHDR am Versatz 67 für die ausgewählte Größe, das heißt bei offset + size lokalisiert, wird erhalten (Block 173), und die Zeiger auf den nachfolgenden Speicherblock 45 p_succlink (Block 174) und den vorangehenden Speicherblock 45 p_predlink (Block 175) für den ausgewählten Speicherblockkopf (11) BHDR werden auf Null gesetzt. Die Verfügbarkeitsmarke f_availtag für den ausgewählten Speicherkopfblock (11) BHDR wird gesetzt, um anzuzeigen, dass er frei ist („TRUE") (Block 176), und der Blockgrößenindikator als Potenz von 2 kval8 für den ausgewählten Speicherblockkopf (11) BHDR wird auf die ausgewählte Blockgröße kval gesetzt (Block 177). Die ausgewählte Blockgröße kval wird hochgezählt, um sie auf die nächstgrößere Blockgröße zu setzen (Block 178), und die Prozedur (Blöcke 171–78) wird wiederholt, bis die ausgewählte Blockgröße kval die zugewiesene Blockgröße supply übersteigt (Block 179), worauf die Prozedur beendet ist (Block 180).
  • Eine Prozedur zum Anpassen der ppls (Block 160) einschließlich jeder ppl der bereitgestellten Speicherpufferkontrollfeldelemente, die auf den obigen Zuweisungs- oder Nichtzuweisungseinflussgrößen beruhen, ist in 18 dargestellt. Deren Zeck ist es, den vorgenannten ppl während eines Datenblockübertragungs-I/O-Ereignisses wie beispielsweise einen readframe()- oder einen swapframe()-Prozeduraufruf, oder nach einem alloc_block()- oder einem free_block()-Prozeduraufruf zu modifizieren. Die Anzahl an Bytes in einem minimalen Speicherblock 45 Paragraph und die minimale Blockgröße MIN_BLKSIZ (Tabelle 3) werden jeweils in den Programmvariablen j und i gespeichert (Block 190). Bei dem beschriebenen Ausführungsbeispiel ist die Anzahl der Bytes in einem minimalen Speicherblock 45 gleich einem Speicherabschnitt mit 16 Bytes, und die minimale Blockgröße ist gleich Eins. Die availmap vor der Zuweisungs- oder der Nichtzuweisungsoperation (wie zuvor in dem Eingangsparameter x gespeichert) wird logisch mit UND mit der gespeicherten kleinsten Anzahl an Bytes j verknüpft, und das Ergebnis wird in der Programmvariablen k gespeichert (Block 191). Dieses Ergebnis k wird mit dem availmap nach der Zuweisungs- oder der Nichtzuweisungsoperation (wie zuvor in dem Eingangsparameter y gespeichert) verglichen und logisch mit der kleinsten Anzahl von Blockgrößenbytes j verknüpft (Block 192). Falls das Ergebnis ein Nichtzusammenpassen anzeigt, wird die Programmvariable k untersucht (Block 193), und falls sie von Null verschieden ist, wird die Seite von der verknüpften Liste i für den Speicherpool pool beseitigt (Block 194), wie unten in 20 beschrieben ist. Falls andererseits die Programmvariable k gleich Null ist (Block 193), wird die Seite zu der verknüpften Liste i für den Speicherpool pool hinzugefügt (Block 195). Die nächste Blockgröße wird durch die Anzahl an Bytes j und die Blockgröße i bestimmt (Block 196), und die Prozedur (Blöcke 191–96) wird wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 197), wonach die Prozedur beendet ist (Block 198).
  • Eine Prozedur zum Hinzufügen einer Seite zu der pplheads-Liste 54 (Block 195), die auf den obigen Einflussgrößen beruht, ist in 19 dargestellt. Deren Zweck ist es, einen Eintrag 71 zu der pplheads-Liste 54 während der Prozedur zum Anpassen der ppls (in 18 dargestellt) hinzuzufügen. Ein Eintrag 71 in der pplheads-Liste 54 pplheads[pool][i] aus dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, wird in der Programmvariablen p gespeichert (Block 210) und untersucht, um zu bestimmen, ob für die ausgewählte Größe ein freier Speicherblock 45 vorhanden ist, das heißt, ob der Eintrag 71 p gleich Null ist (Block 211). Falls er es nicht ist, wird der Zeiger auf die vorangehende Seite ppprev[i] in der ausgewählten Seite CP[p] auf die aktuelle Seite page gesetzt (Block 212). Unabhängig davon wird der anzupassende pplheads-Listeneintrag 71 pplheads[pool][i] auf die ausgewählte Seite page gesetzt (Block 213). Die Zeiger auf die nächste Seite ppnext[i] (Block 214) und die vorangehende Seite ppprev[i] (Block 215) für die ausgewählte Seite CP[page] werden auf die Seite p, auf die der zuvor angepasste Eintrag gezeigt hat (Block 214), beziehungsweise auf Null (Block 215) gesetzt, worauf die Routine beendet ist (Block 216).
  • Eine Prozedur zum Entfernen einer Seite aus der pplhead-Liste (falls erforderlich) (Block 194), die von jeder ppl bereitgestellten Speicherpuffersteuerfeldelemente aufweist, die auf den obigen Einflussgrößen beruht, ist in 20 dargestellt. Deren Zweck ist es, während der Prozedur zum Anpassen der ppls (wie in 18 dargestellt) einen ppl-Eintrag zu entfernen. Die nächste Seite nxt[i] (Block 231) und die vorangehende Seite prv[i] (Block 232) in der ausgewählten Speicherpufferseite CP[page] werden in den Programmvariablen next beziehungsweise prev gespeichert. Falls es eine nächste Seite gibt, das heißt die nächste Seite next ist von Null verschieden (Block 233), wird der Versatz 67 auf die vorangehende Seite prv[i], auf den durch die nächste Seite CP[next] verwiesen wird, auf den Versatz 67 der vorangehenden Seite prev für die ausgewählte Seite gesetzt (Block 234). Falls entsprechend eine vorangehende Seite vorhanden ist, das heißt die vorangehende Seite prev ist von Null verschieden (Block 235), wird der Versatz 67 auf die nächste Seite nxt[i], auf den die vorangehende SeitenCP[prev] verweist, auf den Versatz 67 der nächsten Seite next für die ausgewählte Seite gesetzt (Block 236). Falls andererseits keine vorangehende Seite vorhanden ist, das heißt die vorangehende Seite prev ist Null (Block 235), wird der pplheads-Listeneintrag 71 pplheads[pool][i] von dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, auf die gespeicherte nächste Seite next gesetzt (Block 237). Schließlich werden die Versätze zu der nächsten Seite nxt[i] (Block 238) beziehungsweise der vorangegangenen Seite prv[i] (Block 239) für die ausgewählte Seite CP[page] jeweils auf Null gesetzt, worauf die Prozedur beendet ist (Block 240).
  • Eine Prozedur zum Freigeben eines Speicherblockes 45 ist in 21 dargestellt. Deren Zweck ist es, einen Speicherblock 45 an einem Versatz 67 eines Datenübertragungsblockes auf einer spezifischen Seite in Abhängigkeit einer Speicherfreigabeanfrage von einem Anwendungsprogramm freizugeben. Dies ist das funktionale Gegenteil der Prozedur zum Zuweisen eines Speicherblockes 45 (in 16 dargestellt). Die Verfügbarkeitsbitfolge 60 availmap für den Datenübertragungsblock FHDR, der den freizugebenden Speicherblock 45 enthält, ist in der Programmvariablen oldavail (Block 260) gespeichert, und geeignete zugehörige Blöcke werden mit benachbarten Blöcken zusammengeführt (Block 261), wie unten in 22 erläutert ist. Die Verfügbarkeitsmarke für den Speicherblock 45 f_availtag von dem Blockkopf (11) BHDR wird gesetzt, um anzuzeigen, dass der Speicherblock 45 nun frei ist (Block 262), und der Versatz 67 auf den vorangehenden Speicherblock 45 p_predlink von dem Blockkopf (11) BHDR wird auf Null gesetzt (Block 263). Die Verfügbarkeitsbitfolge 60 availmap für den Datenübertragungs block wird mit einem logischen UND mit der größten Größe size des freigegebenen Speicherblockes 45 (zurückgegeben von der unten in 22 erläuterten Prozedur zum Verschmelzen von zusammengehörigen Blöcken) verknüpft, um zu bestimmen, ob irgendwelche anderen Speicherblöcke 45 der ausgewählten Größe in dem Datenübertragungsblock frei sind (Block 264). Falls dies der Fall ist, wird der Zeiger auf den nachfolgenden Speicherblock 45 p_succlink von dem Blockkopf (11) BHDR auf den Blockversatz 67 des nächsten Speicherblockes 45 der gleichen Blockgröße boffs[kval-1] gesetzt (Block 267). Zusätzlich wird der Speicherblockkopf (11) BHDR für den nachfolgenden Speicherblock 45 successor erhalten (Block 268), und der Versatz 67 auf den vorangegangenen Speicherblock 45 p_predlink der ausgewählten Größe wird auf den Versatz offset gesetzt, der in dem erhaltenen nachfolgenden Speicherblock 45 successor gespeichert ist (Block 269). Falls es keinen Speicherblock 45 der gleichen Blockgröße gibt (Block 264), wird der Versatz 67 auf den vorangehenden Speicherblock 45 p_predlink in dem Blockkopf (11) BHDR der ausgewählten Größe auf Null gesetzt (Block 265), und die Verfügbarkeitsbitfolge 60 availmap wird durch Setzen auf die Summe der vorhandenen Verfügbarkeitsbitfolgen 60 availmap zuzüglich der Anzahl von Bytes der freigegebenen oder nicht mehr zugewiesenen Speicherblockes 45 size aktualisiert, um anzugeben, dass ein Speicherblock 45 der ausgewählten Größe nunmehr frei ist (Block 266).
  • Als nächstes wird die alte Verfügbarkeitsbitfolge 60 oldavail (vor dem Freigeben des Speicherblockes 45) mit der aktuellen Verfügbarkeitsbitfolge 60 availmap (nach Freigeben des Speicherblockes 45) verglichen (Block 270). Falls die beiden Verfügbarkeitsbitfolgen 60 nicht zusammenpassen, werden die ppls der ausgewählten Seite, die jede der ppls der bereitgestellten Speicherpuffersteuerfeldelemente beinhaltet, angepasst (Block 271), wie weiter oben in der Prozedur zum Anpassen der ppls beschrieben worden ist (in 18 dargestellt). Falls die Anzahl der freigegebenen Bytes size geringer als die maximale Zahl an Bytes in einem Speicherblock 45 MAX_BYTES (Tabelle 3) ist, wird der Eintrag 71 für den nächsten Speicherblock 45 der gleichen Blockgröße in dem Blockversatzfeld 62 boffs[kval-1] auf den aktuellen Blockversatz offset gesetzt (Block 273), worauf die Prozedur beendet ist (Block 274).
  • Eine Prozedur zum Zusammenführen von zusammengehörigen Blöcken (Block 261), die auf den obigen Einflussgrößen beruht, ist in 22 gezeigt. Deren Zweck ist es, schrittweise zusammengehörige Blöcke einer Potenz von 2 zusammenzuführen, wann immer ein Speicherblock 45 entsprechend der Prozedur zum Freigeben eines Speicherblockes 45 (in 21 dargestellt) freigegeben wird. Ein Speicherblockkopf (11) BHDR, der an dem ausgewählten Versatz 67 für den freigegebenen Speicherblock 45 offset lokalisiert ist, wird erhalten (Block 290), und die Blockgröße des ursprünglichen freizugebenden Speicherblockes 45 BHDR.kval8 wird in der Programmvariablen kval gespeichert (Block 291). Die Anzahl an Bytes size, die der gespeicherten Blockgröße BYTES(kval) entspricht, wird bestimmt (Block 292), und der Blockkopf (11) für den zusammengehörigen Speicherblock 45 BHDR wird erhalten (Block 293).
  • Falls der zusammengehörige Block nicht in Verwendung ist, das heißt, dass er auch frei ist (Block 294), und falls der zusammengehörige Block von der gleichen Größe wie der freigegebene Speicherblock 45 ist (Block 296), werden der freigegebene Speicherblock 45 und der entsprechende zusammengehörige Block entsprechend des nachfolgenden Satzes von Schritten zusammengeführt. Als erstes wird der zusammengehörige Block von seinem vorangehenden zusammengehörigen Block und seinem nachfolgenden zusammengehörigen Block entknüpft (Block 297), wie unten in 23 erläutert ist. Durch Sammeln des Minimums (MIN()) des Versatzes 67 des freigegebenen Speicherblockes 45 offset und des Versatzes 67 des zusammengehöri gen Blockes buddy block offset wird der neue Versatz 67 bestimmt (Block 298). Die Blockgröße kval wird auf die nächstgrößere Blockgröße hochgesetzt (Block 299). Der Speicherblockkopf (11) BHDR, der an dem neuen Versatz offset lokalisiert ist, wird erhalten (Block 300), und die in dem erhaltenen Blockkopf (11) gespeicherte Blockgröße BHDR.kval8 wird auf die hochgesetzte Blockgröße kval gesetzt (Block 301). Schließlich wird die Verfügbarkeitsmarke f_availtag in dem Blockkopf ( 11) BHDR gesetzt, um anzuzeigen, dass der Speicherblock 45 frei ist (Block 302). Die Prozedur (Blöcke 292–302) wird wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 303) oder der zusammengehörige Block nicht zusammengeführt werden kann, da er in Benutzung ist (Block 294) oder nicht von der gleichen Größe ist (Block 296), worauf die Prozedur den Blockkopf (11) (BHDR), die Blockgröße (kval), die Anzahl an Bytes (size) und den Blockversatz 67 des größten zusammengeführten Blockes (offset) zurückgibt (Block 295).
  • Eine Prozedur zum Entknüpfen eines Speicherblockes 45 (Block 297), die auf den obigen Einflussgrößen beruht, ist in 23 dargestellt. Deren Zweck ist es, einen Speicherblockkopf ( 11) von seinen Verknüpfungen zu anderen Speicherblöcken 45 zu befreien, die in dem ausgewählten Datenübertragungsblock während der Prozedur zum Zusammenführen von zusammengehörigen Blöcken (in 22 dargestellt) auftreten, zu befreien. Der Kopf des zusammengehörigen Blockes BHDR wird erhalten (Block 320), und der Versatz 67 zu seinem vorangehenden zusammengehörigen Block p_predlink (Block 321) und seinem nachfolgenden zusammengehörigen Block p_succlink (Block 322) werden in den lokalen Programmvariablen pred beziehungsweise succ gespeichert. Falls der Versatz des zusammengehörigen Blockes zu dem nachfolgenden Speicherblock 45 succ von Null verschieden ist (Block 323), wird der Blockkopf (11) für den nachfolgenden Speicherblock 45 BHDR erhal ten (Block 324), und der vorangehende Versatz des ausgewählten zusammengehörigen Blockes p_predlink wird auf den Versatz des Vorgängers des nachfolgenden Speicherblockes 45 pred gesetzt (Block 325). Falls der Versatz des zusammengehörigen Blockes auf den vorangegangenen Speicherblock 45 pred von Null verschieden ist (Block 326), wird entsprechend der Blockkopf (11) für den vorangegangenen Speicherblock 45 BHDR erhalten (Block 327), und der Nachfolgerversatz des ausgewählten zusammengehörigen Speicherblockes p_succlink wird auf den Versatz 67 des Nachfolgers des vorangehenden Speicherblockes 45 succ gesetzt (Block 328). Nach Fertigstellen der beiden vorangehenden Abfolgen von Schritten zum Anpassen des vorangehenden Zeigers (Blöcke 323–325) und des nachfolgenden Zeigers (Blöcke 326–328) wird die Blockgröße des zusammengehörigen Blockes kval auf die Blockgröße gesetzt, die in seinem Blockkopf (11) BHDR.kval gespeichert ist (Block 329), und der Eintrag für den entsprechenden Blockversatz 67 für die nächste kleinere Blockgröße boffs[kval-1] wird auf den Versatz 67 des nachfolgenden Speicherblockes 45 succ gesetzt (Block 330). Falls es keinen nachfolgenden Speicherblock 45 succ von dem ausgewählten zusammengehörigen Block gibt (Block 331), wird die Verfügbarkeitsbitfolge 60 availmap über die Differenz der vorhandenen Verfügbarkeitsbitfolge 60 availmap weniger die Anzahl an Bytes für die ausgewählte Blockgröße BYTES(kval) aktualisiert (Block 332), wonach die Prozedur beendet ist (Block 333).
  • Eine Prozedur zum Abfragen der pdb-Liste 70 (Block 108), die auf den obigen Einflussgrößen beruht, ist in 24 dargestellt. Deren Zweck ist es, die pdb-Liste 70 für einen Speicherblock 45 einer ausgewählten Blockgröße während der Prozedur zum Erhalt eines Speicherblockes 45 (in 14 dargestellt) abzufragen. Die Blockgröße für den zuzuweisenden Speicherblock 45 demand wird in der Programmvariablen i gespeichert (Block 350). Der pdb-Listeneintrag 80 pdb[pool][i] aus dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, wird in einer anderen Programmvariablen ci als ein Zählereintrag 80 gespeichert (Block 351). Falls der Zählereintrag 80 ci Null ist, was anzeigt, dass der Zähler des Speicherblockes 45 pdb[pool][i] aus dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, gleich Null ist (Block 352), wird die Blockgröße i auf die nächstgrößere Blockgröße hochgezählt (Block 353), und die Schritte des Speicherns, Vergleichens und Hochsetzens (Blöcke 351-53) werden wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 354) oder bis ein von Null verschiedener Zählereintrag 80 gefunden ist (Block 352). Falls die maximale Blockgröße überschritten ist (Block 354), wird die Datenübertragungsblocknummer 49 auf Null gesetzt (Block 358). Falls ein von Null verschiedener Zählereintrag 80 ci in der pdb-Liste 70 gefunden wird (Block 352), wird der Datenübertragungsblock für den ersten Datenübertragungsblock poolheads[pool] aus dem Speicherunterpool pool in der Programmvariablen frame gespeichert (Block 355), und deren Datenübertragungsblockkopf (10) fhdr wird erhalten (Block 360). Die Verfügbarkeitsbitfolge 60 availmap für den Datenübertragungsblock wird mit der kleinsten Größe des zuzuweisenden Speicherblockes 45 demand verglichen, um zu bestimmen, ob ein freier Speicherblock 45 der ausgewählten freien Blockgröße in diesem Datenübertragungsblock vorhanden ist (Block 356). Falls dies nicht der Fall ist, wird der nächste Datenübertragungsblock frame in dem Speicherunterpool unter Verwendung des Zeigers auf den nächsten Datenübertragungsblock fhdr → fnext ausgewählt (Block 357), und die Schritte des Erhaltens und Vergleichens (Blöcke 360 und 356) werden wiederholt, bis ein Datenübertragungsblock gefunden ist, der einen freien Speicherblock 45 der angeforderten Blockgröße enthält. Die Datenblockübertragungsnummer 49 frame wird an die aufrufende Prozedur zurückgegeben (Block 359).
  • Eine Prozedur zum Anpassen der pdb-Liste 70 (Block 103), die auf den obigen Einflussgrößen beruht, ist in 25 dargestellt. Deren Zweck ist es, die pdb-Liste 70 während eines I/O-Ereignisses wie eines readframe()-, swapframe()- oder rollback()-Vorgangs zu modifizieren, was während den Prozeduren zum Erhalt eines Speicherblockes 45 (in 14 dargestellt) oder zum Freigeben eines Speicherblockes 45 auftritt, wenn der Speicherpuffer nicht ausreichend Platz während einer Datenübertragungsblockübertragung enthält (in 21 dargestellt). Die kleinste Blockgröße MIN_BLKSIZ (Tabelle 3) wird in einer Programmvariablen i gespeichert (Block 370). Die Verfügbarkeitsbitfolge 60 availmap in dem Datenübertragungskopf (10) des ausgewählten Datenübertragungsblockes avail wird logisch über UND mit der Anzahl an Bytes BYTES(i), die der ausgewählten Blockgröße i entspricht, verknüpft (Block 371). Falls dieser Vergleich anzeigt, dass andere Speicherblöcke 45 der ausgewählten Blockgröße vorhanden sind, wird der pdb-Listeneintrag 80 pdb[pool][i] aus dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, positiv oder negativ inkrementiert, um den freien Speicherblockzähler anzupassen (Block 372). Die nächstgrößere Blockgröße wird durch Hochzahlen der ausgewählten Blockgröße i ausgewählt (Block 373), und die Vergleichs- und Inkrementierungsschritte (Blöcke 371–373) werden wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 374), worauf die Prozedur beendet ist (Block 375).
  • Eine Prozedur zum Aktualisieren der pdb-Liste 70 ist in 26 dargestellt. Deren Zweck ist es, die pdb-Liste 70 vor einem Ablage- oder Schließvorgang an einer Datenbankdatei zu aktualisieren. Die kleinste Blockgröße MIN_BLKSIZ (Tabelle 3) wird in einer Programmvariablen i gespeichert (Block 390). Ein Eintrag 80 in einer pdb-Liste 70 pdb[pool][i] aus dem ausgewählten Speicherunterpool pool, der der ausgewählten Blockgröße i entspricht, wird ausgewählt und in pi gespeichert (Block 391). Falls der Eintrag 80 i von Null verschieden ist, was anzeigt, dass es andere freie Speicherblöcke 45 der ausgewählten Blockgröße in dem Datenübertragungsblock in dem ausgewählten Speicherunterpool gibt (Block 392), wird der Eintrag 80 für die pdb-Liste pdb[pool][i] hochgezählt, um den Zähler von freien Speicherblöcken 45 der ausgewählten Blockgröße zu erhöhen (Block 393), die nächste Speicherpufferseite pdb[pool][i] für die ausgewählte Blockgröße wird ausgewählt und in pi gespeichert (Block 394), und der Vorgang (Blöcke 391–394) wird wiederholt. Nachdem alle pdb-Listeneinträge (pdb[pool][i]) untersucht worden sind, wird die Blockgröße i auf die nächstgrößere Speicherblockgröße erhöht (Block 395), und der gesamte Vorgang (Blöcke 391–395) wird erneut wiederholt, bis die maximale Blockgröße MAX_BLKSIZ (Tabelle 3) überschritten ist (Block 396), worauf die Prozeduren beendet sind (Block 397). TABELLE 1
    Blockgröße (<blksiz>) Bytes Speicherabschnitte Verfügbarkeitsbitfolge Bitfolgenbitpositionen
    1 16 1 0×00010 4
    2 32 2 0×00000020 5
    3 64 4 0×00000040 6
    4 128 8 0×00000080 7
    5 256 16 0×00000100 8
    6 512 32 0×00000200 9
    7 1024 64 0×00000400 10
    8 2048 128 0×00000800 11
    9 4096 256 0×00001000 12
    10 8192 512 0×00002000 13
    11 16 KB 1024 0×00004000 14
    12 32 KB 2048 0×00008000 15
    13 64 KB 4096 0×00010000 16
    14 128 KB 8192 0×00020000 17
    15 256 KB 16 K 0×00040000 18
    16 512 KB 32 K 0×00080000 19
    17 1 MB 64 K 0×00100000 20
    18 2 MB 128 K 0×00200000 21
    19 4 MB 256 K 0×00400000 22
    20 8 MB 512 K 0×00800000 23
    TABELLE 2 Datenübertragungskopfverfügbarkeitsbitfolge
    Figure 00440001
    TABELLE 3
    Makroname Vorgabewert Beschreibung
    MAX_BYTES 8 MB maximale Bytes in einem Datenübertragungsblock
    MIN_BLKSIZ 1 Minimum <blksiz>
    MAX_BLKSIZ 20 Maximum <blksiz>
    TABELLE 4A
    FLUSSSCHAUBILD BESCHREIBUNG EINGABEN VARIABLEN AUSGABEN
    Fig. 14: erhalte eine Speicherblockprozedur Finden und Zuweisen eines Speicherblockes in Abhängigkeit einer Speicheranfrage. reqsize: nachgefragte Anzahl an zuzuweisenden Bytes pool: nachgefragter Speicherunterpool zum Zuweisen von demand: minimale <blksiz> zum Zuweisen supply: <biksiz> einer Speicherblockzuweisung ist bereitgestellt von frame: Datenübertragungsblocknummer page: Seitennummer offset: Versatz zum zugewiesenen Speicherblock
    Fig. 15: frage Poolseitenlistekopflistenprozedur ab Abfragen der pplheads-Liste für einen Speicherblock der Größe <blksiz>. demand: minimale <blksiz> zum Zuweisen pool: nachgefragter Speicherunterpool zum Zuweisen von i: <blksiz> des aktuellen pplheads-Listeneintrags pi: pplheads-Listeneintrag supply: <biksiz> der Speicherblockzuweisung ist bereitgestellt von frame: Datenübertragungsblocknummer des Datenübertragungsblockes, der den zuzuweisenden Speicherblock enthält page: Seitennummer des ausgewählten Datenübertragungsblockes
    Fig. 16: Zuweisen einer Speicherblockprozedur weise einen Speicherblock der Größe <biksiz> auf der spezifizierten Seite zu. page: Seite zum Zuweisen von demand: minimale <biksiz> zum Zu-weisen supply: <blksiz> einer Speicherblockzuweisung ist bereitgestellt von oldavail: Vertilgbarkeitsbitfoige für Datenübertragungsblock vor Zuweisen size: Anzahl an zuweisenden Bytes succ: Zeiger auf nachfolgenden Speicherblock offset: Versatz zu dem zugewiesenen Speicherblock
    TABELLE 4B
    FLUSSSCHAUBILD BESCHREIBUNG EINGABEN VARIABLEN AUSGABEN
    Fig. 17: Prozedur zum Aktualisieren der boffs[]-Liste und BHDR's Aktualisieren der Speicherblockversatzlisten und Blockköpfe. demand: minimale <blksiz> zum Zuweisen supply: <blksiz> einer Speicherblockzuweisung ist bereit-gestellt von offset: Versatz zum zugewiesenen Speicherblock kval: minimale <blksiz> zum Zuweisen
    Fig. 18: Prozedur Anpassen der Poolseitenlistenkopflisten Modifizieren der ppl während eines Datenübertragungsblocks-I/O-Ereignisses wie readframe() oder swapframe() oder nach einem alloc_block() oder free_block(). pool: anzupassender Speicherunterpool page: Seitennummer des anzupassenden Speicherblocks x: availmap für Datenübertragungsblock vor Zuweisung oder Freigabe y: availmap des Datenübertragungsblocks vor Zuweisung oder Freigabe paragraph: Anzahl an Bytes in kleinstem <blksiz> Speicherblock i: <blksiz> des anzupassenden ppl-Listeneintrags j: Anzahl an Bytes in einem Speicherblock der Größe <blksiz>, der gleich i ist k: logisches UND des Datenübertragungsblockes und Dateneinheitenindexes
    Fig. 19: Prozedur Hin-zufügen einer Seite zur Poolseitenlistekopfliste Hinzufügen eines pplheads-Listeneintrags während eines ppladjust(). pool: anzupassender Speicherunterpool page: hinzuzufügende Seitennummer zu pplheads-Liste i: <blksiz> der hinzuzufügenden pplheads-Liste p: Eintrag in pplheads-Liste
    TABELLE 4C
    FLUSSSCHAUBILD BESCHREIBUNG EINGABEN VARIABLEN AUSGABEN
    Fig. 20: Prozedur Entfernen einer Seite von Poolseitenlistekopfliste Entfernen eines pplListeneintrags während ppladjust(). pool: Speicherunterpool zum Entfernen von page: von ppl-Liste zu entfernende Seitennummer i: <blksiz> der ppl-Liste zu entfernen von next Seitennummer der nächsten Seite in Speicherpufferliste prev: Seitennummer der vorangegangenen Seite in Speicherpufferliste
    Fig. 21: Prozedur Freigeben eines Speicherblockes Freigeben eines Speicherblockes beim Versatz <offs> auf der angegebenen Seite. page: Seite zum Freigeben eines Speicherblockes von offset: Versatz eines freizugebenden Speicherblockes oldavail: Verfügbarkeitsbitfolge für Datenübertragungsblock vor Freigabe size: Anzahl an Bytes eines freizugebenden oder von einer Zuweisung zu befreienden Speicherblock von Prozedur Zusammenführen zusammengehöriger Blöcke (Fig. 22)
    Fig. 22: Prozedur Zusammenführen zusammengehöriger Blöcke Zusammenführen zusammengehöriger Speicherblöcke. FHDR: Zeiger auf Datenübertragungsblockkopf offset: Versatz des ursprünglich freizugebenden Speicherblockes kval: Speicherblockgröße des freizugebenden Speicherblockes size: Anzahl an Bytes für Speicherblock der Größe kval buddoffs: Versatz zu dem zusammengehörigen Speicherblock BHDR: Zeiger auf Speicherblockkopf kval: Speicherblockgröße des zuletzt freigegebenen Speicherblockes entsprechend Zusammengehörigkeitsblocksystem size: Anzahl an Bytes für Speicherblock der Größe kval offset: Versatz des zuletzt freigegebenen Speicherblockes
    TABELLE 4D
    FLUSSSCHAUBILD BESCHREIBUNG EINGABEN VARIABLEN AUSGABEN
    Fig. 23: Prozedur Entknüpfen eines Speicherblockes Entknüpfen von Speicherblockkopfverknüpfungen auf einen Speicherblock. FHDR: Zeiger auf Datenübertragungsblockkopf buddoffs: Versatz zu dem zusammengehörigen Speicherblock succ: Zeiger auf nachfolgenden zusammengehörigen Speicherblock pred: Zeiger auf vorangehenden zusammengehörigen Speicherblock
    Fig. 24: Prozedur Abfragen Poollaufwerksblockliste Abfragen der pdb-Liste für einen Speicher-block der Größe <blksiz>. demand: kleinste zuzuweisenden <blksiz> pool: angeforderter Speicherunterpool zum Zuweisen von i: <blksiz> des aktuellen pdb-Listeneintrags ci: pdb-Listeneintrag frame: Datenübertragungsblocknummer des Datenübertragungsblockes, der einen Speicherblock der angeforderten Größe enthält
    Fig. 25: Prozedur Anpassen Poollaufwerksblockliste Modifizieren der pdb-Liste während eines Datenübertragungsblocks-I/O-Ereignisses wie readframe(), swapframe() oder rollback(). pool: anzupassender Speicherunterpool avail: availmap des Datenübertragungsblockes incr. anzupassendes Delta durch (±1) i: <blksiz> des anzupassenden pdb-Listeneintrags
    Fig. 26: Prozedur Aktualisieren Poollaufwerksblockliste Aktualisieren der pdb-Liste von der pplheads-Liste vor Lesen oder Schreiben eines Datenübertragungsblockes auf Laufwerk. pool: anzupassender Speicherunterpool i: <blksiz> des anzupassenden pdb-Listeneintrags pi: pdb-Listeneintrag

Claims (3)

  1. Speicherverwaltungssystem für einen Datenspeicher, wobei das Speicherverwaltungssystem eine Speichereinheit (4), die mit wenigstens einer Datei aufgebaut ist, welche Dateneinheiten (40) mit gespeicherten Daten aufweist, einen Speicher (15), der mit Nummern versehene Seiten (46) zum Speichern überlagerter Dateneinheiten der gespeicherten Daten von der Speichereinheit aufweist, wobei der Speicher (15) weiterhin über eine Seitenlistenkopfliste (54), die über eine Anzahl von Listenkopfeinträgen verfügt, wobei jeder Eintrag der Anzahl von Listenkopfeinträgen eine Seite in dem Speicher (15) identifiziert, der eine Dateneinheit speichert, die wenigstens einen freien Speicherblock (45) einer bestimmten Größe aufweist, wobei die Seitenlistenkopfliste auf der Grundlage der freien Speicherblockgrößen aufgebaut ist, und über eine Laufwerkblockliste verfügt, die die eine Anzahl von Zählereinträgen aufweist, wobei jeder Eintrag in der Anzahl der Zählereinträge die Nummern der Dateneinheiten in der Speichereinheit (4) umfasst, die wenigstens einen freien Speicherblock (45) einer bestimmten Größe haben, und einen mit dem Speicher (15) verbundenen Prozessor (8) aufweist, wobei der Prozessor Mittel zum Abfragen der Seitenlistenkopfliste (54) zum Erkennen der Existenz eines bestimmten Eintrags, der eine Seite in dem Speicher (15) identifiziert, der eine Dateneinheit mit wenigstens einem freien Speicherblock einer in einer Speicheranfrage nachgefragten Größe speichert, und auf eine erfolglose Abfrage der Seitenlistenkopfliste (54) reagierende Mittel zum Abfragen der Laufwerkblockliste (70) zum Erkennen der Existenz eines die Anzahl der Dateneinheiten umfassenden Zähleintrags in der Speichereinheit (4) aufweist, der wenigstens einen freien Speicherblock (45) der in der Speicheranfrage nachgefragten Größe aufweist.
  2. Verfahren zum Einsatz mit einem Computer zum Zuordnen eines Speicherblockes mit einer nachgefragten Größe, wobei der Computer über einen Speicher (15), der über mit Zählern versehene Seiten verfügt, um überlagerte Dateneinheiten von gespeicherten Daten aus einer Speichereinheit zu speichern, über eine Seitenlistenkopfliste (54) und über eine Laufwerkblockliste (70) verfügt, wobei die Seitenlistenkopfliste (54) eine Anzahl von Listenkopfeinträgen aufweist, wobei jeder Eintrag in der Anzahl von Listenkopfeinträgen eine Seite in dem Speicher (15) identifiziert, die eine Dateneinheit speichert, die wenigstens einen freien Speicherblock einer bestimmten Größe aufweist, wobei die Seitenlistenkopflisten (54) auf der Grundlage von freien Speicherblockgrößen aufgebaut sind und wobei die Laufwerkblockliste (70) eine Anzahl von Zählereinträgen aufweist, wobei jeder Eintrag in der Anzahl von Zählereinträgen die Nummer von Dateneinheiten in der Speichereinheit (4) umfasst, die wenigstens einen freien Speicherblock einer bestimmten Größe aufweisen, wobei das Verfahren den Empfang einer Speicheranfrage für einen Speicherblock mit einer nachgefragten Größe aufweist, gekennzeichnet durch Abfragen der Seitenlistenkopfliste (51), die auf die Speicheranfrage reagierend ist, um die Existenz eines bestimmten Listenkopfeintrags festzustellen, der eine Seite in dem Speicher (15) identifiziert, die eine Dateneinheit mit wenigstens einem freien Speicherblock (45) der in der Speicheranfrage nachgefragten Größe aufweist, als Reaktion auf eine erfolglose Abfrage der Seitenlistenkopfliste (54) Abfragen der Laufwerkblocklisten (70) zum Feststellen der Existenz eines bestimmten die Nummer der Dateneinheiten enthaltenden Zählereintrags in der Speichereinheit (4), der wenigstens einen freien Speicherblock der in der Speicheranfrage nachgefragten Größe aufweist, und Zuordnen eines Speicherblocks mit der in der Speicheranfrage nachgefragten Größe.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass jeder der Speicherblöcke eine festgelegte Blockgröße aufweist und dass die Seitenlistenkopfliste (54) entsprechend der festgelegten Blockgrößen aufgebaut ist.
DE69637329T 1995-08-31 1996-09-03 Speichermanagementsystem und verfahren Expired - Lifetime DE69637329T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US311795P 1995-08-31 1995-08-31
US3117 1995-08-31
US565862 1995-12-01
US08/565,862 US5835959A (en) 1995-12-01 1995-12-01 Memory management system and method using dual indexing structures
PCT/US1996/014084 WO1997008622A1 (en) 1995-08-31 1996-09-03 Memory management system and method

Publications (2)

Publication Number Publication Date
DE69637329D1 DE69637329D1 (de) 2008-01-03
DE69637329T2 true DE69637329T2 (de) 2008-10-09

Family

ID=26671348

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69637329T Expired - Lifetime DE69637329T2 (de) 1995-08-31 1996-09-03 Speichermanagementsystem und verfahren

Country Status (6)

Country Link
EP (1) EP0928451B1 (de)
JP (1) JP2001520770A (de)
AU (1) AU713318B2 (de)
CA (1) CA2230859C (de)
DE (1) DE69637329T2 (de)
WO (1) WO1997008622A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4018433B2 (ja) 2002-04-15 2007-12-05 キヤノン株式会社 記録装置
JP4401618B2 (ja) 2002-04-15 2010-01-20 キヤノン株式会社 記録装置、及び、バッファ管理方法
US7747834B2 (en) 2004-09-30 2010-06-29 Kyocera Wireless Corp. Memory manager for an embedded system
CN104598385B (zh) * 2013-10-30 2019-05-10 华为技术有限公司 内存分配方法及装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3596257A (en) * 1969-09-17 1971-07-27 Burroughs Corp Method and apparatus for allocating small memory spaces to a computer program
US5109336A (en) * 1989-04-28 1992-04-28 International Business Machines Corporation Unified working storage management
US5249265A (en) * 1989-10-24 1993-09-28 International Business Machines Corporation Structure storage management in a graphics display device
US5339411A (en) * 1990-12-21 1994-08-16 Pitney Bowes Inc. Method for managing allocation of memory space
JPH0546447A (ja) * 1991-08-08 1993-02-26 Hitachi Ltd 空き領域検索方法
WO1994002898A1 (en) * 1992-07-24 1994-02-03 Microsoft Corporation Computer method and system for allocating and freeing memory
US5561785A (en) * 1992-10-29 1996-10-01 International Business Machines Corporation System for allocating and returning storage and collecting garbage using subpool of available blocks
US5577243A (en) * 1994-03-31 1996-11-19 Lexmark International, Inc. Reallocation of returned memory blocks sorted in predetermined sizes and addressed by pointer addresses in a free memory list

Also Published As

Publication number Publication date
WO1997008622A1 (en) 1997-03-06
DE69637329D1 (de) 2008-01-03
EP0928451B1 (de) 2007-11-21
EP0928451A4 (de) 2004-05-19
JP2001520770A (ja) 2001-10-30
AU713318B2 (en) 1999-11-25
AU7153896A (en) 1997-03-19
EP0928451A1 (de) 1999-07-14
CA2230859C (en) 2002-12-31
CA2230859A1 (en) 1997-03-06

Similar Documents

Publication Publication Date Title
DE69636761T2 (de) Speichern und wiederauffinden von geordneten schlüsselmengen in einem kompakten 0-kompletten baum
DE69738101T2 (de) Verwaltung des Zugangs zu Objekten mit Hilfe von Referenzen mit drei Zuständen
DE10055603B4 (de) Verfahren zum Zugriff auf eine Datei in einer Vielzahl von Datenspeicherbibliotheken und Datenspeicherbibliothek-System
DE102012216022B4 (de) Verwaltung einer Zeitpunktkopie-Beziehung für platzsparende Datenträger
DE60224432T2 (de) Dynamische und automatische speicherverwaltung
DE19961499A1 (de) Caching von Objekten in Platten-gestützten Datenbanken
DE60129025T2 (de) Speicherbereichszuordnung in einem dateisystem zum beschreiben beliebiger bereiche
DE2459006C2 (de) Einrichtung zum Bilden einer absoluten Adresse in einer Datenverarbeitunsanlage
DE69838367T2 (de) Paralleles Dateiensystem und Verfahren zur unabhängigen Aufzeichnung von Metadaten
DE60313783T2 (de) Bewegen von daten zwischen speichereinheiten
DE4410060B4 (de) Übersetzungsvorrichtung zum Umsetzen einer virtuellen Speicheradresse in eine physikalische Speicheradresse
DE69737709T2 (de) Verfahren und Vorrichtung für Informationsverarbeitung und Speicherzuordnungsanordnung
DE3151745C2 (de)
DE4221073A1 (de) Datenspeichersystem und -verfahren mit geraeteunabhaengigen dateiverzeichnissen
DE102012212183B4 (de) Verfahren und Speichercontroller zur Bestimmung einer Zugriffscharakteristik einer Datenentität
DE10219623A1 (de) System und Verfahren zur Speicherentscheidung unter Verwendung von mehreren Warteschlangen
DE202010017665U1 (de) Datenverteilung bei einer Datenspeichervorrichtung mit Flash-Speicherchips
DE4218025A1 (de) Datenspeicherverwaltungssystem und verfahren mit speicherzuordnung auf der basis nachgefragter dienstklassen
DE602004007925T2 (de) Verwalten einer beziehung zwischen einem zielvolumen und einem quellenvolumen
DE69130626T2 (de) Verfahren zur Verwaltung einer Cache-Speicheranordnung
DE112019000627T5 (de) Speicherstrukturbasiertes Coherency Directory Cache
DE60003426T2 (de) Statusbits für cachespeicher
DE69637329T2 (de) Speichermanagementsystem und verfahren
DE102006059626A1 (de) Verfahren zum Auslesen von Daten aus einem Speichermedium
EP0912952B1 (de) Datenbanksystem und verfahren zum verwalten eines n-dimensionalen datenbestands

Legal Events

Date Code Title Description
8364 No opposition during term of opposition