DE10120615A1 - Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe - Google Patents

Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe

Info

Publication number
DE10120615A1
DE10120615A1 DE10120615A DE10120615A DE10120615A1 DE 10120615 A1 DE10120615 A1 DE 10120615A1 DE 10120615 A DE10120615 A DE 10120615A DE 10120615 A DE10120615 A DE 10120615A DE 10120615 A1 DE10120615 A1 DE 10120615A1
Authority
DE
Germany
Prior art keywords
memory
sub
blocks
block
stored
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.)
Granted
Application number
DE10120615A
Other languages
English (en)
Other versions
DE10120615B4 (de
Inventor
Fridtjof Siebert
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.)
Aicas GmbH
Original Assignee
Aicas GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aicas GmbH filed Critical Aicas GmbH
Priority to DE10120615A priority Critical patent/DE10120615B4/de
Publication of DE10120615A1 publication Critical patent/DE10120615A1/de
Application granted granted Critical
Publication of DE10120615B4 publication Critical patent/DE10120615B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management

Abstract

In Verbindung mit Schreib-Lese-Speichern stellt sich das Problem einer nachlassenden Speichereffizienz durch eine zunehmende Fragmentierung des Speichers in Form von freigegebenen Speicherplätzen. DOLLAR A Die Erfindung löst dieses Problem dadurch, daß dem Speicher eine Speicherverwaltung zugeordnet wird, die unterschiedliche Methoden der Speicherung beherrscht und somit bedarfsweise zwischen einer zusammenhängenden und einer verteilten Speicherung auswählt. DOLLAR A JAVA-Implementierung.

Description

Die Erfindung betrifft ein Verfahren zur dynamischen Ver­ waltung eines Schreib-Lese-Speichers. Derartige Schreib- Lese-Speicher werden bei nahezu sämtlichen Datenverarbei­ tungssystemen genutzt. Im Zusammenhang mit derartigen Spei­ chern, insbesondere RAM-Speichern, besteht das Problem, daß der zunächst unbelegte Speicher nach und nach mit Objekten unterschiedlicher Größe belegt wird. Dabei erfolgt zunächst eine kompakte Belegung des Speichers, d. h. die gespeicher­ ten Objekte werden nacheinander unter optimaler Ausnutzung des Speichers im Speicher angelegt. Wenn nun einzelne Ob­ jekte gelöscht werden, entstehen Lücken im Speicher. Grund­ sätzlich ist der zuvor belegte Speicherplatz somit wieder beschreibbar. Allerdings ist nun der Speicher fragmentiert. Dies bedeutet, daß der Speicher aus beschriebenen und frei­ en Speicherplätzen unterschiedlicher Größe besteht. Dabei besteht das Problem, daß oftmals eigentlich genügend frei­ er, aber nicht genügend freier Speicherplatz in der jeweils benötigten Größe zur Verfügung steht. Der Anteil des Spei­ chers, der durch diese Fragmentierung verlorengeht, kann mitunter erheblich sein.
Zu einer verbesserten Speicherverwaltung stehen daher Sy­ steme zur Verfügung, die eine Kompaktierung des Speichers vorsehen. So sind beispielsweise Verfahren bekannt, bei denen genutzter Speicher derart in einen weiteren Speicher­ bereich umgespeichert wird, daß eine zusammenhängende Spei­ cherung entsteht und der frei werdende Platz somit eben­ falls als zusammenhängender freier Speicherplatz zur Verfü­ gung steht.
Alternativ sind auch Verfahren bekannt, in denen belegte Speicher derart zusammengeschoben werden, daß ein größerer zusammenhängender freier Speicherbereich entsteht.
Bei beiden vorstehend erläuterten Verfahren der Speicher­ verwaltung besteht das Problem, daß bereits zugewiesene Speicherplätze verschoben werden müssen. Es ist daher er­ forderlich, sämtliche Referenzen mit denen bestimmte Spei­ cherblöcke angesprochen werden, neu zu adressieren. In der Regel wird dies durch relativ aufwendige Verweisungstechni­ ken erledigt, so daß im Ergebnis der Zugriff auf den Spei­ cher verlangsamt ist. In jedem Fall ergibt sich eine ver­ stärkte Prozessorbelastung.
Ein weiteres Problem der vorstehenden Techniken besteht darin, daß das Verschieben von Speicherobjekten als aufwen­ dig bezeichnet werden muß. In diesen Zeiten steht der Spei­ cher nicht zur Nutzung zur Verfügung. Die vorstehenden Lö­ sungen sind daher zum Einsatz in Verbindung mit Echtzeitsy­ stemen, beispielsweise der Automatisisierungstechnik, unzu­ reichend. Als Stand der Technik gibt es Ansätze um dieses Problem durch eine stufenweise Verschiebung zu lösen. Hier­ durch soll der Speicher weiterhin benutzbar bleiben. Es stellt sich das Problem, daß Vorkehrungen geschaffen werden müssen, daß einzelne Anwendungen auch in Verbindung mit bereits teilweise verschobenen Objekten lauffähig bleiben. Im Ergebnis ergibt sich auch hier ein verlangsamter Spei­ cherzugriff bzw. eine Verlangsamung des Datenverarbeitungs­ systems insgesamt.
Eine alternative Lösung des Problems besteht darin, grund­ sätzlich alle zu speichernden Objekte gleicher Größe abzu­ legen. Hierdurch ist sichergestellt, daß der Speicher grundsätzlich kompakt belegt werden kann. Problematisch dabei ist, daß erheblicher Speicherbedarf dafür verwendet wird, daß alle Objekte in einer Größe abgelegt werden müs­ sen, der dem größten anzunehmenden Objekt entspricht. Al­ ternativ ist auch eine Unterteilung aller Objekte in klei­ nere gleich große Teilobjekte vorstellbar. Die generelle Aufspaltung in Teilobjekte hat wiederum den Nachteil, daß grundsätzlich eine Verweisverwaltung vorgesehen werden muß, um die in Teilblöcke unterteilten Objekte zusammen zu füh­ ren.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfah­ ren zur Verwaltung eines Schreib-Lese-Speichers zu schaf­ fen, das die vorstehend erläuterten Nachteile nach Möglich­ keit vermeidet und bei möglichst gleichbleibender Rechner- und Speicherleistung eine optimale Speicherausnutzung er­ laubt.
Die der Erfindung zugrunde liegende Aufgabe wird mittels eines Verfahrens zur dynamischen Verwaltung eines Schreib- Lese-Speichers gemäß Hauptanspruch gelöst. Dabei liegt der Erfindung die Idee zugrunde, den Speicher mit einer Spei­ cherverwaltung zu versehen, die mehrere, zumindest zwei, unterschiedliche Verfahren der Speicherung mit entsprechen­ der Verwaltung beherrscht und demgemäß in Abhängigkeit von dem zu speichernden Objekt und dem aktuell vorhandenen Speicherzustand die jeweils geeignete Speichermethode aus­ wählt. In der Regel wird die Speichermethode in Abhängig­ keit von der Größe des zu speichernden Objektes im Bezug zur Größe des jeweils freien Speicherplatzes gewählt wer­ den. Hierzu versteht die Speicherverwaltung den Speicher zunächst grundsätzlich als in gleich große Teilblöcke un­ terteilt, wobei sie in Abhängigkeit von der vorstehend er­ läuterten Bedingung unterscheidet, ob ein zu speicherndes Objekt in aufeinanderfolgenden Blöcken, also zusammenhän­ gend gespeichert wird, oder verteilt angelegt wird.
Im Falle der Speicherung eines Objekts in Form von verteil­ ten Teilblöcken werden die Teilblöcke dieses Objekts je­ weils mit Links derart versehen, daß alle Teilblöcke dieses Objekts über Links verbunden sind. Es handelt sich um die sogenannte Speicherung in Form eines Graphen.
Je nach Art und Größe der einzelnen Objekte wird eine be­ stimmte Speichermethode ausgewählt. Beispielhaft können Instanzen von Klassen grundsätzlich verteilt angeordnet werden.
In vorteilhafter Ausgestaltung legt die Speicherverwaltung zusätzlich, zumindest für einen Teil der verteilt gespei­ cherten Objekte, eine mit Links verkettete Liste der ein­ zelnen Teilblöcke an.
Im Sinne eines möglichst schnellen Speicherzugriffs ist es im Falle der verteilten Speicherung sinnvoll, eine Baum­ struktur zu wählen. Dabei werden die verteilt gespeicherten Teilblöcke in Form eines verzweigten Baumes miteinander verlinkt.
Eine weitere Erhöhung der Effizienz der Speicherverwaltung in Verbindung mit diesen Baumstrukturen gelingt dadurch, daß jedem Baum ein Wurzelblock zugeordnet wird, das die wesentlichen Informationen über das in Form eines Baumes gespeicherten Objektes, beispielsweise dessen Größe, ent­ hält.
In vorteilhafter Ausgestaltung ist in dem Wurzelblock eine Kennzahl über die Verzweigungstiefe des Baumes abgelegt.
Eine verbesserte Speicherverwaltung ergibt sich auch da­ durch, daß jedem Teilblock ein Speicherflag zugeordnet wird, das eine Information darüber enthält, ob der jeweili­ ge Teilblock Bestandteil eines zusammenhängend gespeicher­ ten Objektes oder eines verteilt gespeicherten Objektes ist. Für den Fall, daß die Speicherverwaltung lediglich zwischen zwei Speicherverfahren unterscheidet, kann es sich bei dem Flag um ein einfaches Bit handeln.
In vorteilhafter Ausgestaltung kann das Speicherflag ledig­ lich in einem ungenutzten BIT des jeweiligen Teilblocks ab gelegt werden. Hierdurch wird Speicherplatz gespart.
In Verbindung mit den vorstehend erläuterten Wurzelblöcken ist es sinnvoll, wenn der Wurzelblock eine Kennzahl über die jeweilige Verzweigungstiefe des zugehörigen Baumes ent­ hält.
Dabei kann in dem den Wurzelbock darstellenden Teilblock das Speicherflag und die Kennzahl über die Verzweigungstie­ fe des Baumes sinnvoll zu einem einzigen Speicherelement zusammengefaßt werden. Hierdurch wird abermals der Spei­ cherbedarf reduziert.
In Verbindung mit den als zusammenhängender Block gespei­ cherten Objekten kann eine zusätzliche Linkliste angelegt werden, die sicherstellt, daß alle Teilblöcke eines Objekts über Links vom ersten Teilblock erreichbar sind. Dabei er­ kennt die Speicherverwaltung; daß die beteiligten Teilblöc­ ke Bestandteil eines gemeinsamen Objekts sind.
In abermals vorteilhafter Ausgestaltung legt die Speicher­ verwaltung einen Bitvektor an, wobei jedes Bit einem Teilblock des Speichers entspricht. Dabei enthält jedes Bit des Bitvektors eine Information darüber, ob zwei aufeinan­ derfolgende Blöcke Teilblöcke desselben Objektes sind.
In alternativer Ausgestaltung kann jedem Teilblock des Speichers ein Objektflag zugeordnet sein, das anzeigt, ob zwei aufeinanderfolgende Teilblöcke Bestandteile desselben Objektes sind. Dabei gilt für die Belegung der Objektflag dasselbe was zuvor für die einzelnen Bits des Bitvektors gesagt wurde.
Die Erfindung wird nachstehend anhand mehrerer in der Zeichnung nur schematisch dargestellten Ausführungsbeispie­ le näher erläutert.
Es zeigen:
Fig. 1 eine dem Stand der Technik entsprechende Speicherverwaltung in einer Prinzipdarstel­ lung,
Fig. 2 einen Speicher mit Speicherverwaltung,
Fig. 3 eine Speicherung eines Objekts in zusammen­ hängenden und verteilten Teilblöcken jeweils mit einem Speicherflag,
Fig. 4 eine Speicherung desselben Objekts mit ver­ teilten Teilblöcken ohne Speicherflag,
Fig. 5 die Speicherung eines weiteren Objekts mit zusammenhängenden Teilblöcken und mit ver­ teilt in einer Baumstruktur angelegten Teilblöcken mit einem Speicherflag,
Fig. 6 eine Speicherung des Objektes aus Fig. 5 als zusammenhängender Block und mit verteilt in . einer Baumstruktur gespeicherten Teilblöcken mit einem kombinierten Speicherflag,
Fig. 7 Speicherung eines weiteren Objektes als zu­ sammenhängender Block mit einer zusätzlichen Linkliste,
Fig. 8 Speicherung eines weiteren Objekts als zu­ sammenhängender Block mit einem zugeordneten Bitvektor,
Fig. 9 Speicherung eines Java-Objekts in zwei ver­ teilten Blöcken und
Fig. 10 Speicherung eines weiteren Java-Objektes mit zwei zugeordneten Bitvektoren.
Fig. 1 zeigt eine herkömmliche Speicherverwaltung mit einem Speicher 1, in dem verschiedene Objekte OB1 bis OB3 in den Speicherbereichen abgelegt sind. Zwischen den Objekten OB1 bis OB3 finden sich inzwischen frei gewordene Speicherplät­ ze, die jedoch als solche nicht hinreichend groß sind, um ein weiteres Objekt OB4 in dem Speicher 1 zusammenhängend anzuordnen.
Als Stand der Technik sind, zur Lösung dieses Problems Soft­ waretools bekannt, mit denen die Objekte OB1 bis OB3 derart umgespeichert bzw. verschoben werden können, daß die beleg­ ten Speicherplätze sowie die unbelegten Speicherplätze an­ schließend jeweils zusammenhängend angeordnet sind, so daß der fragmentierte Speicher 1 in einen unfragmentierten Speicher 1' überführt wird. Danach ist der frei werdende Speicherplatz FS 4 hinreichend groß um das Objekt OB4 auf­ zunehmen.
Das Problem derartiger Speicherfragmentierungen besteht darin, daß der Speicher zu Zeiten der Umorganisation des Speichers 1 üblicherweise nicht zum Zugriff bereitsteht. Eine derartige Lösung ist daher für Echtzeitsysteme in der Regel nicht anwendbar.
Im Rahmen der erfindungsgemäßen Lösung wird daher dem Spei­ cher 1 gemäß der Darstellung in Fig. 2 eine Speicherverwal­ tung 2 zugeordnet, die den Speicher zunächst in gleich gro­ ße Teilblöcke B1-Bn, zumindest virtuell, aufteilt. Die Speicherverwaltung 2 kann ein zusätzlicher Prozessor, eine Prozessorfunktion oder ein im Arbeitsspeicher eines Prozes­ sors eines Datenverarbeitungssystems lauffähiges Software­ tool sein.
Nach dieser realen oder virtuellen Unterteilung des Spei­ chers 1 ergeben sich für die Speicherung von Objekten meh­ rere Möglichkeiten, wobei im Rahmen der Erfindung die Spei­ cherverwaltung 2 jeweils zumindest zwei unterschiedliche Methoden der Speicherung beherrscht.
Beispielhaft sind in Fig. 3 zwei mögliche Methoden der Speicherung zusammengestellt, die von dem Speicherelement zumindest beherrscht werden. Es könnte sich dabei zum einen um eine Speicherung in Form zusammenhängender Teilblöcke gemäß der linken Darstellung in Fig. 3 oder um eine ver­ teilte Speicherung gemäß der rechten Darstellung in Fig. 3 in Form von drei verteilt angeordneten Teilblöcken 3', 4', 5' handeln, wobei die verteilt angeordneten Teilblöcke 3', 4', 5' jeweils durch einen Link L miteinander verbunden sind. Der Link L auf den jeweils nächsten Block wird in dem Teilblock selbst, wie beispielsweise hier in den Teilblöc­ ken 3' und 4' angelegt.
Ein Speicherflag F im hier vorliegenden Falle von zwei mög­ lichen Speicherungen gibt darüber Auskunft, welche Art der gewählten Speicherung vorliegt. Im vorliegenden Beispiel steht der Flagwert F = 0 für eine zusammenhängende und der Flagwert F = 1 für eine verteilte Speicherung.
Gemäß der Darstellung in Fig. 4 ist selbstverständlich auch eine Speicherung ohne das genannte Speicherflag F möglich. Der von dem zu speichernden Objekt belegte Speicherplatz fällt entsprechend geringer aus.
Eine alternative Form der Speicherung ist in Fig. 5 darge­ stellt. Gemäß der linken Darstellung in Fig. 5 kann auch eine Speicherung eines Objektes in Form von zusammenhängend abgelegten Teilblöcken 3, 4, 5 und 6 oder eine Speicherung in Form von verteilt gespeicherten Teilblöcken 10 bis 14 gemäß der rechts angeordneten Darstellung in Fig. 5 erfol­ gen. Dabei weist sowohl die zusammenhängende Speicherung gemäß der links angeordneten Darstellung in Fig. 5 sowie auch die verteilte Anordnung gemäß der rechts angeordneten Darstellung in Fig. 5 eine Speicherflag F auf. Beiden Dar­ stellungen gemeinsam ist, daß die Speicherverwaltung in dem als ersten Teilblock 3 bzw. 10 ein der Klasse des jeweili­ gen Objektes entsprechende Klassenelement 15 sowie ein der Länge des Objektes entsprechendes Längenelement 16 vorgese­ hen ist. Die Speicherelemente 15 und 16 stellen somit an sich nicht Bestandteile des abzuspeichernden Objektes son­ dern vielmehr der Identifikation des Objektes dar. Diese Informationen erlauben eine komfortablere Speicherverwal­ tung.
Die Auswahl der Speichermethode erfolgt dabei bei den vor­ stehenden wie auch den nachfolgenden Methoden der Speicher­ verwaltung beispielsweise danach, wie sich der zur Verfü­ gung stehende freie Speicherplatz FS zur Größe der zu spei­ chernden Objekte OB verhält. Im Regelfall wird die zusam­ menhängende Speicherung dann gewählt, wenn der freie Spei­ cherplatz FS dies zuläßt. Sollte dies nicht möglich sein, wird in der Regel auf eine verteilte Speicherung zurückge­ griffen.
In dem in Fig. 5 dargestellten Ausführungsbeispiel ist das Speicherobjekt in einer Baumstruktur angelegt. Eine derar­ tige Baumstruktur empfiehlt sich beispielsweise in Verbin­ dung mit der Speicherung von Arrays.
Gemäß der rechten Darstellung in Fig. 5 enthält das erste Teilobjekt der Baumstruktur den sogenannten Wurzelblock 10 neben einem Link L lediglich Informationen, die das gespei­ cherte Objekt als solches beschreiben. Hierzu zählt neben Klassenelement 15 und dem Längenelement 16 auch eine Kenn­ zahl K der Verzweigungstiefe. Die Verzweigungstiefe beträgt im vorliegenden Falle 2. Bei einer speicherplatzoptimierten Anordnung kann dabei das Speicherflag F und die Kennzahl K in einem gemeinsamen Speicherelement kombiniert werden.
Eine derart kombinierte Darstellung ist in der rechten Dar­ stellung von Fig. 6 ersichtlich, die im übrigen vollständig der Darstellung in Fig. 5 entspricht.
Der Vorteil der in Fig. 5 und 6 dargestellten Baumstruktu­ ren besteht darin, daß auf die einzelnen Teilblöcke 12, 13, 14 von einer Stelle, nämlich vom Wuzelblock 10 aus schnel­ ler zugegriffen werden kann, als dies bei einer Liste, wie rechts in Fig. 3 dargestellt möglich wäre. Hierzu besteht der Teilblock 11 besteht aus einer Linkliste, wobei die Links auf die Teilblöcke 12, 13, 14 der Baumstruktur ver­ weisen.
Eine Linkliste kann gemäß Fig. 7 auch in Verbindung mit einem gemäß Fig. 7 zusammenhängend gespeicherten Objekt sinnvoll sein. Bei der zusammenhängenden Speicherung ist es für eine Speicherverwaltung 2 unter bestimmten Umständen nicht möglich, anhand der Information, wie sie etwa gemäß Fig. 3 in Verbindung mit den Teilblöcken 4 und 5 abgespei­ chert sind, zu bestimmen, ob die Teilblöcke 4 und 5 als Bestandteil eines gemeinsamen Objektes mit Teilblock 3 an­ zusehen sind.
Diese Information ergibt sich erst in Verbindung mit den im Teilblock 3 gespeicherten Informationen insbesondere aus dem Klassenelement 15. Dieser Zusammenhang ergibt sich für die verteilte Speicherung nach Fig. 3 für die Teilblöcke 3' und 4' schon aus der bloßen Existenz der Linkelemente L.
Aus diesem Grund kann es daher sinnvoll sein, gemäß der Darstellung Fig. 7 zusätzlich zu der zusammenhängenden Speicherung jeweils eine weitere Linkliste in den Teilblöc­ ken 20 und 21 anzulegen. Dies hat zunächst den Vorteil, daß alle an einem Objekt beteiligten Teilblöcke 3, 4, 5, 6 über ein einziges Linkelement L des Teilblocks 3 erreichbar sind.
Bei einer alternativen oder zusätzlichen Ausgestaltung kann gemäß Fig. 8 in Verbindung mit einer zusammenhängenden Speicherung der Teilblöcke 3, 4, 5, 6 und 7 ein Bitvektor 17 angelegt sein, der zu jedem Teilblock 3, 4, 5, 6 ein Bit enthält, das darüber Auskunft gibt, ob der folgende Teilblock Bestandteil desselben Objektes ist oder nicht. Im vorliegenden Falle gehören die Teilblöcke 3, 4, 5 und 6 demselben Teilobjekt an. Entsprechend sind die in der Dar­ stellung des Bitvektors 17 von oben nach unten die ersten drei Bits gesetzt. Der Teilblock 7 ist Bestandteil eines anderen Objektes oder nicht belegt. Dementsprechend ist das in der Darstellung des Bitvektors 17 von oben gezählte vierte Bit nicht gesetzt, da der nachfolgende Block 7 nicht demselben Objekt angehört.
Gemäß Fig. 9 ist eine andere Möglichkeit dargestellt, wie die Speicherverwaltung 2 darüber befinden kann, welche Me­ thode der Speicherung gewählt wird. Im vorliegenden Bei­ spiel gibt das Klassenelement 15 darüber Auskunft, daß es sich bei dem zu speichernden Objekt um eine Instanz handelt. Demzufolge wählt die Speicherverwaltung 2 grund­ sätzlich eine verteilte Speicherung im vorliegenden Bei­ spiel in Form von durch Linkelementen L verbundenen Teilblöcken 3 und 4 aus.
Wie aus Fig. 9 deutlich wird, kann also die Methode der Speicherung auch in Abhängigkeit von der Art des zu spei­ chernden Öbjektes bestimmt werden.
Gemäß einer besonderen Ausführung der Erfindung kann die erfindungsgemäße Speicherverwaltung zur Implementierung einer virtuellen Java-Maschine verwendet werden. Hierbei stellt die virtuelle Java-Maschine die Speicherverwaltung 2 dar. Sofern Instanzen grundsätzlich verteilt gemäß Fig. 9 angeordnet werden, muß kein Speicherflag F gesetzt und kein entsprechender Speicherplatz belegt werden.
In Verbindung hiermit kann es sinnvoll sein, daß ein zu­ sätzlicher Bitvektor 18 angelegt wird, der zu jedem Spei­ cherelement eines Teilblocks 3, 4, 5, 6 eine Information darüber enthält, ob es sich bei dem jeweiligen Speicherele­ ment bzw. Wort um ein Linkelement L handelt oder nicht. Zusätzlich zu dem Bitvektor 18 ist auch in Verbindung mit der Speicherung von Instanzen gemäß Fig. 10 die Verwendung des Bitvektors 17 sinnvoll, der angibt, ob der jeweils nachfolgende Teilblock Bestandteil desselben Objektes ist oder nicht.
Vorstehend ist somit ein Verfahren der Speicherverwaltung beschrieben, das sich dadurch auszeichnet, jeweils unter­ schiedliche Speichermethoden zu beherrschen, die in Abhängigkeit von dem zu speichernden Objekt und dem jeweiligen Speicherangebot ausgewählt werden.
BEZUGSZEICHENLISTE
OB1-OB4 Objekte
FS Freier Speicherplatz
L Linkelement
F Speicherflag
K Kennzahl
1
Speicher
2
Speicherverwaltung
3-6
Teilblöcke
10
Wurzelblock
11
Linkliste
12-14
Baum-Teilblöcke
15
Klassenelement
16
Längenelement
17
Bitvektor
18
weiterer Bitvektor
20
,
21
weitere Linklisten

Claims (15)

1. Verfahren zur dynamischen Verwaltung eines Schreib-Lese-Speichers (1), in dem Objekte unterschied­ licher Größe gespeichert und gelöscht werden können,
wobei der Schreib-Lese-Speicher (1) in Speicherblöcke (3-6) definierter Größe unterteilt und dem Schreib- Lese-Speicher (1) eine Speicherverwaltung (2) zugeord­ net ist, die die zu speichernden Objekte nach zumindest zwei unterschiedlichen Methoden der Speicherung
als ein aus Teilblöcken zusammengesetzter, aber zu­ sammenhängender Block oder
ein aus verteilt angeordneten Teilblöcken zusammenge­ setzter Block,
wobei die Auswahl der jeweiligen Speichermethode auf­ grund vorgebbarer Bedingungen, vorzugsweise in Abhän­ gigkeit von der Größe des freien Speichers im Bezug auf die Größe des freien Objektes derart erfolgt, daß wenn der freie Speicherplatz größer, gleich der Größe des zu speichernden Objektes ist, das Objekt zusammenhängend und sonst verteilt gespeichert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Speicherverwaltung (2) bei der verteilten Spei­ cherung die einzelnen Teilblöcke (3-6) miteinander durch Verwendung von Links (L) miteinander verbindet, wobei die Links (L) in Verbindung mit den Teilblöcken (3-6) abgespeichert werden.
3. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß zumindest ein Teil der Objek­ te, vorzugsweise Instanzen von Klassen, grundsätzlich verteilt gespeichert werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß die Speicherverwaltung (2) zumindest für einen Teil der verteilt gespeicherten Objekte eine Liste mit Links (11, 15, 16) auf die Teilobjekte (4, 5, 6) anlegt.
5. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß zumindest ein Teil der ver­ teilt gespeicherten Objekte in Form eines verzweigten Baumes aus Teilblöcken (10-14) gespeichert wird.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß zu jedem aus Teilblöcken bestehenden Baum ein weiterer Teilblock, ein Wurzelblock (10), mit Informationen über das jeweils gespeicherte Objekt angelegt wird.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der Wurzelblock (10) eine Kennzahl (K) über die Ver­ zweigungstiefe des Baums enthält.
8. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß zumindest einem Teil der Ob­ jekte ein Speicherflag (F) zugeordnet wird, wobei das Speicherflag (F) die Information enthält, ob es sich jeweils um einen zusammenhängend gespeicherten Teilblock oder um einen verteilt gespeicherten Teilblock handelt.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß das Speicherflag (F) jeweils in einem ungenutzten Bit des Objekts gespeichert wird.
10. Verfahren nach Anspruch 5 bis 9, dadurch gekennzeich­ net, daß im Wurzelblock ein Speicherflag angelegt ist.
11. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeich­ net, daß das Speicherflag (F) und die Kennzahl (K) zu­ sammengefaßt, vorzugsweise in einem Wort und/oder Spei­ cherelement des Wurzelobjekts (10) abgelegt wird.
12. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Speicherverwaltung (2) zumindest für einen Teil der als zusammenhängender Block aus Teilblöcken (3, 4, 5, 6) gespeicherten Objek­ te eine zusätzliche Linkliste (15, 16) derart anlegt, daß vom ersten Teilblock (3) des Objektes alle weiteren Teilblöcke (4, 5, 6) erreichbar sind.
13. Verfahren nach einem der vorhergehenden Ansprüche 1 bis 11, dadurch gekennzeichnet, daß die Speicherverwaltung (2) zumindest für einen Teil der als zusammenhängender Block aus Teilblöcken -(3, 4, 5, 6, 7) gespeicherten Ob­ jekte einen Bitvektor (17) anlegt, wobei jedes Bit des Bitvektors (17) einem Teilblock (3, 4, 5, 6) des ver­ walteten Speichers (1) eindeutig zugeordnet ist und je­ weils anzeigt, ob der jeweils folgende Teilblock Be­ standteil desselben gespeicherten Objektes ist.
14. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, daß jedem Teilblock (3-6) des Spei­ chers (1) ein Objektflag zugeordnet ist, das anzeigt, ob zwei aufeinanderfolgende Teilblöcke des Speichers (1) Bestandteile desselben gespeicherten Objektes sind.
15. Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, daß ein weiterer Bitvektor (18) vorge­ sehen ist, bei dem jedem Speicherelement jeweils ein Bit zugeordnet ist und dieses Bit in Abhängigkeit davon gesetzt wird, ob dieses Speicherelement ein Link (L) ist.
DE10120615A 2000-04-26 2001-04-26 Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe Expired - Lifetime DE10120615B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE10120615A DE10120615B4 (de) 2000-04-26 2001-04-26 Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10020430 2000-04-26
DE10020430.9 2000-04-26
DE10120615A DE10120615B4 (de) 2000-04-26 2001-04-26 Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe

Publications (2)

Publication Number Publication Date
DE10120615A1 true DE10120615A1 (de) 2001-12-20
DE10120615B4 DE10120615B4 (de) 2004-08-19

Family

ID=7639980

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10120615A Expired - Lifetime DE10120615B4 (de) 2000-04-26 2001-04-26 Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe

Country Status (2)

Country Link
US (1) US6704851B2 (de)
DE (1) DE10120615B4 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10235380B4 (de) * 2002-08-02 2014-10-09 Robert Bosch Gmbh Verfahren zur dynamischen Speicherverwaltung

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7111141B2 (en) * 2000-10-17 2006-09-19 Igt Dynamic NV-RAM
US6804763B1 (en) 2000-10-17 2004-10-12 Igt High performance battery backed ram interface
US8550922B2 (en) 2006-03-03 2013-10-08 Igt Game removal with game history
US7325118B2 (en) * 2003-09-30 2008-01-29 Samsung Electronics, Co., Ltd. Method and apparatus for executing dynamic memory management with object-oriented program
US7856523B2 (en) * 2005-06-01 2010-12-21 Microsoft Corporation Random Access Memory (RAM) based Content Addressable Memory (CAM) management
US7793040B2 (en) * 2005-06-01 2010-09-07 Microsoft Corporation Content addressable memory architecture
US7951008B2 (en) * 2006-03-03 2011-05-31 Igt Non-volatile memory management technique implemented in a gaming machine
US20150278010A1 (en) * 2012-11-23 2015-10-01 Freescale Semiconductor, Inc. Digital device
US9652766B1 (en) * 2013-08-22 2017-05-16 Amazon Technologies, Inc. Managing data stored in memory locations having size limitations

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US6101590A (en) * 1995-10-10 2000-08-08 Micro Unity Systems Engineering, Inc. Virtual memory system with local and global virtual address translation
US5784699A (en) * 1996-05-24 1998-07-21 Oracle Corporation Dynamic memory allocation in a computer using a bit map index
US6085296A (en) * 1997-11-12 2000-07-04 Digital Equipment Corporation Sharing memory pages and page tables among computer processes

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10235380B4 (de) * 2002-08-02 2014-10-09 Robert Bosch Gmbh Verfahren zur dynamischen Speicherverwaltung

Also Published As

Publication number Publication date
DE10120615B4 (de) 2004-08-19
US20020016896A1 (en) 2002-02-07
US6704851B2 (en) 2004-03-09

Similar Documents

Publication Publication Date Title
DE10120615A1 (de) Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe
DE2758829C2 (de) Datenverarbeitungsanlage mit mehreren Prozessoren
DE2423265C3 (de) Optimierende Rechenmaschine
DE112018006540T5 (de) Dynamisches ersetzen eines aufrufs einer software-bibliothek durch einen aufruf eines beschleunigers
DE2133638C3 (de) Verfahren zum Betrieb eines lernfähigen Systems aus in Kaskade geschalteten, zur nicht linearen Datenverarbeitung geeigneten lernfähigen Datenverarbeitungseinheiten
DE69432507T2 (de) Verfahren und Geräte zur Erzeugung von Zeichnungsdaten
DE69629540T2 (de) Verfahren und Gerät zum Sortieren von Elementen
DE19939764A1 (de) Verfahren zum Betrieb eines Speichersystems sowie Speichersystem
DE2558417A1 (de) Datenverarbeitungssystem
DE2246405C3 (de) Schaltungsanordnung zum Adressieren eines Speichersystems mit logischen Adressen
EP0964600B1 (de) Vorrichtung und Verfahren zur Abbildung von Objektadressen
DE102021124009A1 (de) Verfahren zum Erzeugen eines dreidimensionalen Modells eines Objektes zum Steuern eines 3D-Druckers
EP1429254B1 (de) Interrupt-Behandlung in einem CAN-Knoten
WO2023102583A1 (de) Verfahren zur additiven fertigung eines werkstücks
EP1293938A2 (de) Binärzähler mit permutierten Speicherung
DE4211678A1 (de) Betriebssystemarchitektur für Betriebssysteme mit objektorientierter graphischer Benutzeroberfläche
WO2007110326A1 (de) Verfahren zur belegung eines speichers
EP0217232A1 (de) Schaltungsanordnung zur Generierung von Splitting-Adressen
DE10116275A1 (de) Verfahren zur komprimierten Speicherung von Triangulationsdaten
DE10008516A1 (de) Abstimmung des Betriebsverhaltens einer Betätigungseinrichtung
WO2001042923A2 (de) Verfahren zum speichern von daten in einer datei eines datenspeichersystems
DE2451984A1 (de) Datenverarbeitungssystem
WO2005001780A1 (de) Speicherverwaltung bei einem tragbaren datenträger
DE19821581A1 (de) Speichermatrix, die mehrfache, gleichzeitige Schreibzugriffe zuläßt
Reischuk et al. Vergleich von Speicherstrukturen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
R071 Expiry of right