DE10120615A1 - Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe - Google Patents
Dynamische Speicherverwaltung für Objekte unterschiedlicher GrößeInfo
- 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
Links
- 230000015654 memory Effects 0.000 title claims abstract description 102
- 238000000034 method Methods 0.000 claims abstract description 38
- 239000013598 vector Substances 0.000 claims description 16
- 230000001427 coherent effect Effects 0.000 claims description 7
- 230000001419 dependent effect Effects 0.000 description 3
- 235000013305 food Nutrition 0.000 description 2
- 241001432959 Chernes Species 0.000 description 1
- 235000010678 Paulownia tomentosa Nutrition 0.000 description 1
- 240000002834 Paulownia tomentosa Species 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 210000004072 lung Anatomy 0.000 description 1
- 230000007334 memory performance Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
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
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.
OB1-OB4 Objekte
FS Freier Speicherplatz
L Linkelement
F Speicherflag
K Kennzahl
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.
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.
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)
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)
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)
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 |
-
2001
- 2001-04-26 US US09/843,010 patent/US6704851B2/en not_active Expired - Lifetime
- 2001-04-26 DE DE10120615A patent/DE10120615B4/de not_active Expired - Lifetime
Cited By (1)
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 |