Tragbare Datenträger werden mit immer mehr Speicherplatz und immer größerer Rechenleistung hergestellt. In einem internen Forschungsprojekt der Giesecke & Devrient GmbH wird gegenwärtig untersucht, inwieweit ein UNIXO-artiges Betriebssystem in einem modernen tragbaren Datenträger implementiert werden kann. In diesem Zusammenhang ist insbesondere eine Implementierung des unter der Marke Linux (E) bekannten Betriebs- systems vorgesehen. Das Buch"Understanding the Linux Kernel"von D. P.

Bovet und M. Cesati, O'Reilly Verlag, 2. Auflage, Dezember 2002, enthält eine detaillierte technische Beschreibung dieses Betriebssystems.

Die bei dem Linux-Betriebssystem üblicherweise eingesetzten Speicherver- waltungstechniken sind in Kapitel 7 des erwähnten Buches eingehend erläutert. Im Zusammenhang mit der vorliegenden Erfindung ist insbeson- dere die Beschreibung des Slab Allocator (Slab = Platte, Tafel, Scheibe) auf den Seiten 239-255 relevant. Der Slab Allocator dient zur Zuteilung und Ver- waltung von Speicherabschnitten, die eine relative geringe Größe aufweisen und/oder für jeweils gleichartige Objekte benötigt werden.

Bei dem genannten Slab Allocator wird für jeden Objekttyp ein eigenes Lager (Cache) angelegt. Jedes Lager weist einen oder mehrere Slabs mit einer innerhalb des Lagers einheitlichen Größe von einer oder mehreren Spei- cherseiten auf. Hierbei wird die Slabgröße in Abhängigkeit von der festen Größe der in dem jeweiligen Lager zu speichernden Datenelemente derart

festgelegt, daß jeder Slab stets mehrere Datenelemente des jeweiligen Objekt- typs aufzunehmen vermag. Diese Vorgehensweise beruht auf der Be- obachtung, daß die bei vielen Linux-Anwendungen auftretenden Speicher- anforderungen mit überwiegender Häufigkeit nur einige wenige Objekt- typen betreffen.

Bei den Forschungsarbeiten der Giesecke & Devrient GmbH hat sich jedoch gezeigt, daß die genannte Beobachtung für typische Anwendungen von tragbaren Datenträgern nicht zutrifft. Hier werden während der Pro- grammlaufzeit zwar nur relativ wenige Datenelemente neu angelegt ; diese weisen aber unterschiedliche Objekttypen und Größen auf. Bei dem bekann- ten Slab Allocator würde hier für jeden neuen Objekttyp ein weiteres Lager mit einer Mindestgröße von einer Speicherseite, also z. B. 4 KByte, angelegt werden. Relativ zu dem insgesamt zur Verfügung stehenden Speicherplatz, der bei tragbaren Datenträgern nach wie vor deutlich geringer ist als z. B. bei einem üblichen Arbeitsplatzrechner, stellt dies eine erheblich ins Gewicht fal- lende Verschwendung dar.

Die Erfindung hat daher die Aufgabe, die genannten Probleme zu lösen und einen Speicherverwaltungsmechanismus bereitzustellen, der speziell auf die Gegebenheiten bei tragbaren Datenträgern zugeschnitten ist. Insbesondere soll durch die Erfindung der bei tragbaren Datenträgern relativ knappe zur Verfügung stehende Speicherplatz möglichst gut genutzt werden. In vorteil- haften Weiterentwicklungen soll die Erfindung überdies nur geringen zu- sätzlichen Verwaltungsaufwand verursachen.

Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1, einen tragbaren Datenträger gemäß Anspruch

12 und ein Computerprogrammprodukt gemäß Anspruch 13. Die abhängi- gen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.

Die Erfindung geht von der Grundüberlegung aus, die Lager zumindest zum Teil für Datenelemente unterschiedlicher Größen vorzusehen. Genauer ge- sagt, ist erfindungsgemäß zumindest manchen der Lager-und in manchen Ausgestaltungen allen Lagern-je ein Größenbereich zugeordnet, der mehr als eine Größe umfaßt. Für jedes angeforderte Datenelement wird ein Spei- cherabschnitt in einem der Lager angelegt, und zwar derart, daß die Größe des Speicherabschnitts in den dem jeweiligen Lager zugeordneten Größenbe- reich fällt. Auf diese Weise entstehen Lager, die Speicherabschnitte mehrerer unterschiedlicher Größen enthalten.

Bei dem hier zugrundegelegten Einsatz der Erfindung in einem tragbaren Datenträger wird die Nutzung des vorhandenen Speicherplatzes erheblich verbessert. Für jeden Größenbereich muß nur noch ein Lager angelegt wer- den. Wollte man dagegen-als Gedankenexperiment-den an sich bekann- ten Slab Allocator bei einem tragbaren Datenträger einsetzen, so würden viele Lager mit je mindestens einer Speicherseite Umfang angelegt werden, die dann zum großen Teil leer bleiben würden. Für eine praktische Realisierung auf heutigen Chipkarten wäre eine derartige Platzverschwendung nicht akzeptabel.

Die Erfindung unterscheidet sich auch vorteilhaft von den an sich bekannten General Caches bei Linux-Systemen, weil auch hier jeder General Cache nur Speicherabschnitte je einer fest vorgegebenen Größe aufweist.

Um ein erfindungsgemäßes Lager mit Speicherabschnitten unterschiedlicher Größen zu verwalten, ist möglicherweise ein etwas höherer Aufwand als bei

Lagern mit nur je einer Größe erforderlich. Dieser allenfalls geringfügig höhere Verwaltungsaufwand kann jedoch insbesondere bei Anwendungen für tragbare Datenträger in Kauf genommen werden.

In bevorzugten Ausgestaltungen wird jedes Lager nur bei Bedarf angelegt, um den vorhandenen Speicherplatz besonders gut zu nutzen. Ein solcher Bedarf wird vorzugsweise erst dann angenommen, wenn der erste in den jeweiligen Größenbereich fallende Speicherabschnitt benötigt wird.

Allgemein ist die Erfindung stets dann einsetzbar, wenn eine Speicherver- waltung unter Verwendung von Lagern (Caches) vorgesehen ist. In bevor- zugten Ausgestaltungen sind jedoch als weitere Organisationseinheit Slabs (Platten, Tafeln, Scheiben) vorgesehen. Jedes Lager weist dann ein oder mehrere Slabs auf, wobei in jedem Slab Speicherabschnitte unterschiedlicher Größen, die jeweils in den dem Lager zugeordneten Größenbereich fallen, angelegt werden. In manchen Ausführungsformen können die Slabs an den Seitengrenzen des Speichers ausgerichtet sein, wobei jeder Slab eine oder mehrere Speicherseiten umfassen kann.

Um möglichst wenig Speicherplatz ungenutzt zu lassen, ist bevorzugt vorge- sehen, daß mehrere in einem Lager befindliche Speicherabschnitte lückenlos aneinander anschließen. In Ausgestaltungen, die Slabs einsetzen, weisen vor- zugsweise die Slabs diese Eigenschaft auf. Dies schließt nicht aus, daß sich am Anfang und/oder Ende der Lager und/oder Slabs Verwaltungsinforma- tionen oder freie Speicherabschnitte befinden. Ebenfalls zur möglichst guten Nutzung des Speicherplatzes wird jeder Speicherabschnitt vorzugsweise mit genau der Größe des zu speichernden Datenelements angelegt. Alternativ dazu kann, wenn eine bestimmte Ausrichtung des Datenelements im Spei- cher wünschenswert ist-z. B. eine Ausrichtung an den Wortgrenzen des

Speichers-zum Erzielen dieser Ausrichtung ein geringfügiger Verschnitt in Kauf genommen werden.

In bevorzugten Ausgestaltungen wird eine interne Fragmentierung inner- halb der Lager vermieden, indem ein freigegebener Speicherabschnitt eines Lagers nur zur Speicherung eines Datenelements herangezogen wird, das dieselbe Größe wie das ursprünglich in diesem Speicherabschnitt befindliche Datenelement aufweist. Eine irgendwie geartete Defragmentierung ist dann nicht erforderlich. Bei Ausführungsformen, die Slabs verwenden, kann eben- falls eine Defragmentierung innerhalb der Lager vermieden werden, indem nur leere Slabs freigegeben werden. Alternativ oder zusätzlich kann vorgese- hen sein, einen freigegebenen Speicherabschnitt nur wieder zur Speicherung eines Datenelements desselben Typs wie das ursprüngliche Datenelement zu verwenden. Auf dies Weise können aufwendige Initialisierungsvorgänge vermieden werden.

In bevorzugten Ausgestaltungen weist jeder Größenbereich eine obere und eine untere Grenze auf, die sich um je einen Zweierpotenzfaktor voneinan- der unterscheiden. Jede der beiden Grenzen kann entweder noch Teil des Größenbereichs sein oder nicht mehr zum Größenbereich gehören. Die Grö- ßenbereiche überlappen sich vorzugsweise nicht, so daß jeder anzulegende Speicherabschnitt in genau einen Größenbereich fällt. In anderen Ausgestal- tungen wird das für die Anlage eines Speicherabschnitts zu verwendende Lager nach weiteren Kriterien aus mehreren Lagern, die jeweils einen pas- senden Größenbereich aufweisen, bestimmt.

Wie eingangs bereits erwähnt, weist der Datenträger vorzugsweise ein UNIX-artiges Betriebssystem auf. In bevorzugten Ausgestaltungen wird durch die Erfindung ein aus dem Linux-Betriebssystem an sich bekanntes

Speicherverwaltungssystem, nämlich der sogenannte Slab Allocator, in vor- teilhafter Weise modifiziert. Die Erfindung kann jedoch auch für andere Betriebs-und Speicherverwaltungssysteme eingesetzt werden, bei denen ähnliche Gegebenheiten vorliegen. Dies sind insbesondere"Kleinst-Betriebs- systeme"für erheblich ressourcenbeschränkte Datenverarbeitungsgeräte.

Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein Halb- leiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerpro- grammprodukt kann jedoch auch ein nicht-körperliches Medium sein, bei- spielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbeson- dere kann das Computerprogrammprodukt ein Betriebssystem oder ein Speicherverwaltungsmodul enthalten, das im Zuge der Herstellung oder der Initialisierung oder der Personalisierung eines tragbaren Datenträgers in diesen eingebracht wird.

In bevorzugten Ausgestaltungen weisen der Datenträger und/oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/oder den in den abhängigen Verfahrensansprüchen genannten Merk- malen entsprechen.

Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der fol- genden genauen Beschreibung mehrerer Ausführungsbeispiele und Ausfüh- rungsalternativen hervor. Es wird auf die schematischen Zeichnungen ver- wiesen, in denen zeigen : Fig. 1 ein Blockdiagramm mit Funktionseinheiten eines Datenträgers nach einem Ausführungsbeispiel der Erfindung, und

Fig. 2 eine schematische Darstellung der Struktur eines in einem Speicher angelegten Lagers in einem gegenüber der Darstellung von Fig. 1 abgewan- delten Ausgestaltung.

Der in Fig. 1 dargestellte Datenträger 10 weist auf einem einzigen Halbleiter- chip einen Prozessor 12, einen Speicher 14 und eine Schnittstellenschaltung 16 zur kontaktlosen oder kontaktgebundenen Kommunikation mit einem ex- ternen Terminal (nicht gezeigt) auf. Der Speicher 14 ist in mehrere Speicher- felder unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfel- 'der ein als RAM ausgestalteter Arbeitsspeicher 18, ein als ROM ausgestalte- ter Festwertspeicher 20 und ein als EEPROM ausgestalteter, nicht-flüchtiger Speicher 22 vorgesehen.

Im Speicher 14-und zwar teils im Festwertspeicher 20 und teils im nicht- flüchtigen Speicher 22-befindet sich Programmcode, der ein Betriebssystem 24 implementiert. Das Betriebssystem 24 ist im vorliegenden Ausführungs- beispiel eine auf den Einsatz im Datenträger 10 zugeschnittene Variante des unter der Marke Linux bekannten Betriebssystems. Insbesondere ist das Be- triebssystem 24 an die erhebliche Ressourcenbeschränkung des Datenträgers 10 im Hinblick auf die Rechenleistung des Prozessors 12 und die Größe des Speichers 14 angepaßt.

Das Betriebssystem 24 weist ein Speicherverwaltungsmodul 26 auf. Das Speicherverwaltungsmodul 26 stellt Schnittstellen bereit, über die andere Be- triebssystemteile und Anwendungsprogramme Speicherplatz anfordern und freigeben können. Der angeforderte Speicherplatz wird im nicht-flüchtigen Speicher 22 in Lagern (Caches) angelegt. In Fig. 1 sind beispielhaft drei Lager 28A, 28B, 28C gezeigt, während in Ausführungsalternativen weniger oder mehr Lager vorgesehen sein können.

Das Lager 28A weist Verwaltungsinformationen 30 und eine Mehrzahl von Speicherabschnitten 32A-32G unterschiedlicher Größen auf. Jeder Speicher- abschnitt 32A-32G dient zur Aufnahme eines Datenelements 34A-34F. In der beispielhaften Darstellung von Fig. 1 sind die Speicherabschnitte 32A- 32F mit den Datenelementen 34A-34F belegt, während der Speicherab- schnitt 32G frei ist.

Die Lager 28B, 28C-und, falls vorhanden, weitere Lager-weisen die gleiche Struktur wie das gerade beschriebene Lager 28A auf ; sie sind jedoch aus Gründen der Übersichtlichkeit in Fig. 1 nicht detailliert dargestellt. Im folgenden werden daher, wenn allgemein von Lagern, Speicherabschnitten und Datenelementen des Datenträgers 10 die Rede ist, die generischen Bezugszeichen 28x, 32x und 34x verwendet.

Die Speicherabschnitte 32x schließen innerhalb des Lagers 28x unmittelbar aneinander an. Überdies weist im hier beschriebenen Ausführungsbeispiel jeder Speicherabschnitt 32x die gleiche Größe wie das darin gespeicherte Datenelement 34x auf. In Ausführungsalternativen wird dagegen bei der Anlage der Datenelemente 34x eine gegebenenfalls erforderliche Ausrich- tung (alignment) berücksichtigt, indem beispielsweise alle oder manche Da- tenelemente 34x derart angelegt werden, daß sie jeweils an einer Wortgrenze im nicht-flüchtigen Speicher 22 beginnen. Wenn diese Ausrichtung bei einem Datenelement 34x nicht schon zufällig gegeben ist, ergibt sich ein gewisser Verschnitt, um den der Speicherabschnitt 32x größer als das darin gespei- cherte Datenelement 34x ist.

Jedem Lager 28x ist ein vorbestimmter Größenbereich für die darin anzule- genden Speicherabschnitte 32x zugeordnet. So werden in der beispielhaften

Darstellung von Fig. 1 im Lager 28A Speicherabschnitte 32x angelegt, die zwischen 1 Byte und 64 Bytes groß sind. Im Lager 28B werden Speicher- abschnitte mit einer Größe im Bereich von 65 Bytes bis 256 Bytes angelegt, und der dem Lager 28C zugeordnete Größenbereich beträgt. 257 Bytes bis 512 Bytes. Im vorliegenden Ausführungsbeispiel überschneiden sich die Größenbereiche somit nicht. Die Grenzen der Größenbereiche, nämlich 1 Byte, 64 Bytes, 256 Bytes und 512 Bytes, unterscheiden sich um je einen Faktor, der eine Zweierpotenz darstellt, nämlich im vorliegenden Beispiel um die Faktoren 64,4 und 2.

Es versteht sich, daß in Ausführungsalternativen andere oder zusätzliche Größenbereiche vorgesehen sein können. In Abhängigkeit von den beim Betrieb des Datenträgers 10 erwarteten Speicheranforderungen ist es vorteil- haft, diese Größenbereiche so zu definieren, daß die Lager 28x ungefähr gleich schnell gefüllt werden. In vielen Ausgestaltungen ist eine maximale Größe für die in den Lagern 28x anzulegenden Speicherabschnitte 32x vor- gesehen. Anforderungen größerer Speicherabschnitte werden dann vorzugs- weise durch einen anderen Mechanismus-z. B. das an sich bekannte Buddy System-bearbeitet.

Bei der Einrichtung des Datenträgers 10 werden die Lager 28x zunächst noch nicht oder nur rudimentär angelegt. Wenn während des Betriebs des Daten- trägers 10 nun bei dem Speicherverwaltungsmodul 26 eine Anforderung zur Zuweisung von Speicherplatz für ein Datenelement 34x eingeht, wird zu- nächst die Größe des benötigten Speicherabschnitts 32x bestimmt. Das Spei- cherverwaltungsmodul 26 ordnet diese Größe dann einem der vordefinier- ten Größenbereiche zu, um zu bestimmen, in welchem Lager 28x der Spei- cherabschnitt 32x angelegt werden soll. Falls dieses Lager 28x zum ersten Mal benötigt wird, wird es erst zu diesem Zeitpunkt im nicht-flüchtigen

Speicher 22 angelegt. Dann wird der benötigte Speicherabschnitt 32x im Lager 28x zugeteilt. Das Datenelement 34x kann nun-wahlweise gesteuert vom Speicherverwaltungsmodul 26 oder von dem aufrufenden Programm- in diesem Speicherabschnitt 32x gespeichert werden.

Auf diese Weise erfüllt das Speicherverwaltungsmodul 26 sukzessive die eingehenden Speicheranforderungen, wobei neu benötigte Speicher- abschnitte 32x im jeweiligen Lager 28x jeweils unmittelbar im Anschluß an die bisherigen Speicherabschnitte 32x angelegt werden. Bei jeder neuen Spei- cheranforderung überprüft das Speicherverwaltungsmodul 26 ferner, ob im jeweiligen Lager 28x noch genügend Platz für den neu benötigten Speicher- abschnitt 32x vorhanden ist. Ist dies nicht der Fall, kann in unterschiedlichen Ausgestaltungen entweder ein neues Lager 28x angelegt oder das bestehen- de Lager 28x erweitert werden.

Das Speicherverwaltungsmodul 26 vermerkt ferner die Freigabe von Spei- cherabschnitten 32x. Solche freigegebenen Speicherabschnitte 32x werden im hier beschriebenen Ausführungsbeispiel bei der nächsten Anforderung eines Speicherabschnitts 32x mit einer genau passenden Größe neu zugeteilt. Auf diese Weise wird eine interne Fragmentierung innerhalb der Lager 28x ver- mieden. In Ausführungsalternativen kann dagegen ein freigegebener Spei- cherabschnitt 32x auch mit einem neuen Datenelement 34x gefüllt werden, das kleiner als das ursprüngliche Datenelement 34x ist. Hierdurch werden entstehende Lücken in den Lagern 28x schneller wieder gefüllt ; es bildet sich jedoch mit zunehmender Betriebsdauer immer mehr Verschnitt.

Es sind auch Ausgestaltungen vorgesehen, bei denen das Speicherverwal- tungsmodul 26 den Typ jedes in einem Speicherabschnitt 32x gespeicherten Datenelements 34x vermerkt und den Speicherabschnitt 32x nach einer Frei-

gabe nur wieder zur Speicherung eines neuen Datenelements 34x desselben Typs verwendet. Diese Ausgestaltung ist besonders dann vorteilhaft, wenn die Datenelemente 34x Objekte mit einer komplexen Struktur sind. Bei der Anlage des neuen Datenelements 34x kann dann ein potentiell aufwendiger Initialisierungsvorgang im Zusammenhang mit der Ausführung einer Konstruktor-Methode vermieden werden.

Fig. 2 zeigt eine besonders bevorzugte Ausgestaltung eines Lagers 28', das Verwaltungsdaten 30'und mehrere Slabs 36A, 36B, 36C-zusammenfassend mit 36x bezeichnet-aufweist. Die Ausführungsform nach Fig. 2 orientiert sich an dem bei Linux-Systemen an sich bekannten Slab Allocator, der auf den Seiten 239-255 des eingangs genannten Buches"Understanding tlie Linux Kernel"im Detail beschrieben ist. Als Hauptunterschied ist zu nennen, daß vorliegend in den einzelnen Slabs 36x Speicherabschnitte 32x unterschied- licher Größen für Datenelemente 34x angelegt werden. Die einzelnen Spei- cherabschnitte 32x innerhalb jedes Slabs 36x schließen jeweils unmittelbar aneinander an. In Fig. 2 sind aus Gründen der Übersichtlichkeit nur bei einem der dargestellten Speicherabschnitte und einem der dargestellten Datenelemente die Bezugszeichen 32x bzw. 34x angegeben.

Die in Fig. 2 dargestellten Slabs 36x belegen je eine Seite des nicht-flüchtigen Speichers 22, also z. B. 4 KBytes. Insbesondere zur Speicherung großer Daten- elemente 34x kann ein Slab 36x auch mehrere Speicherseiten umfassen. Die Slabs 36x sind jedoch stets an den Speicherseitengrenzen (in Fig. 2 durch kurze waagerechte Striche angedeutet) ausgerichtet. Jedem Slab 36x sind Verwaltungsinformationen 38A, 38B, 38C zugeordnet. In dem Ausführungs- beispiel von Fig. 2 sind die Verwaltungsinformationen 38x im jeweiligen Slab 36x gespeichert, während sie in Ausführungsalternativen in externen Spei- cherbereichen abgelegt werden.

Im Beispiel von Fig. 2 ist der Slab 36A vollständig mit Datenelementen 34x belegt. Der Slab 36B ist zwar aufgrund von früheren Belegungen vollständig in Speicherabschnitte 32x unterschiedlicher Größen unterteilt ; diese Spei- cherabschnitte 32x sind jedoch sämtlich freigegeben und noch nicht neu belegt worden. Der Slab 36C weist teils belegte und teils freie Speicher- abschnitte 32x auf. Weil die Gesamtgröße der in einem Slab 36x gebildeten Speicherabschnitte 32x in der Regel nicht mit dem im Slab 36x zur Verfü- gung stehenden Speicherplatz übereinstimmt, weist jeder Slab 36x einen Verschnitt 40A, 40B, 40C auf. Im ungünstigsten Fall ist dieser Verschnitt 40x um ein Byte kleiner als der größte in dem Lager 28'anzulegende Speicherab- schnitt 32x ; in der Praxis kann jedoch der Verschnitt 40x oft noch zur Anlage von Speicherabschnitten 32x genutzt werden, die eine Größe an der unteren Grenze des für das Lager 28'definierten Größenbereichs aufweisen.

Das Lager 28'mit der in Fig. 2 gezeigten Struktur ist in einem Datenträger nach dem vorliegend beschriebenen Ausführungsbeispiel mehrfach enthal- ten, wobei jedem dieser Lager 28'ein eigener Größenbereich für die darin anzulegenden Speicherabschnitte 32x zugeordnet ist. So kann beispielsweise der Datenträger 10 gemäß Fig. 1 derart abgewandelt werden, daß jedes der dort gezeigten Lager 28A, 28B, 28C wie das Lager 28'gemäß Fig. 2-aber natürlich mit unterschiedlichen Größenbereichen-ausgestaltet ist.

Der Betrieb eines so abgewandelten Datenträgers 10 erfolgt wie oben in Zusammenhang mit Fig. 1 beschrieben, wobei nun die Slabs 36x als weitere Organisationseinheit innerhalb der Lager 28x verwendet werden. Insbeson- dere bearbeitet das Speicherverwaltungsmodul 26 eine Speicheranforderung dadurch, daß in dem Lager 28x mit dem jeweils zugeordneten Größenbe- reich entweder ein neuer oder ein freigegebener Speicherabschnitt 32x mit

der gewünschten Größe angelegt bzw. zugeteilt wird. Ist dies nicht möglich - weil nämlich in den bestehenden Slabs 36x des Lagers 28x weder genügend freier Platz noch ein freigegebener Speicherabschnitt 32x mit genau passen- der Größe vorhanden ist-, so wird ein neuer Slab 36x im Lager 28x angelegt.

Die Anlage von Slabs 36x in einem Lager 28x erfolgt also nur bei Bedarf.

Freigegebene Speicherabschnitte 32x werden in den Verwaltungsdaten 38x vermerkt und stehen für zukünftige Zuteilungen zur Verfügung. Wenn ein Slab 36x keine belegten Speicherabschnitte 32x mehr aufweist-in Fig. 2 der Slab 36B-, dann kann in manchen Ausgestaltungen der gesamte Slab 36x freigegeben und aus dem Lager 28'gelöscht werden. Vorzugsweise erfolgt eine solche Freigabe eines Slabs 36x jedoch erst dann, wenn anderweitig Speicherplatzbedarf besteht. Ein teilweise mit Datenelementen 34x belegter Slab 36x-in Fig. 2 der Slab 36C-wird im hier beschriebenen Ausführungs- beispiel nie freigegeben, während in Ausführungsalternativen bei großer Speicherknappheit Maßnahmen zur Defragmentierung und Zusammen- legung mehrerer teilweise belegter Slabs 36x ergriffen werden.