WO2005093580A1 - Speicherbereinigung (garbage collection) für smart cards - Google Patents

Speicherbereinigung (garbage collection) für smart cards Download PDF

Info

Publication number
WO2005093580A1
WO2005093580A1 PCT/EP2005/002552 EP2005002552W WO2005093580A1 WO 2005093580 A1 WO2005093580 A1 WO 2005093580A1 EP 2005002552 W EP2005002552 W EP 2005002552W WO 2005093580 A1 WO2005093580 A1 WO 2005093580A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
memory
algorithm
referenced
heap
Prior art date
Application number
PCT/EP2005/002552
Other languages
English (en)
French (fr)
Inventor
Jörn TREGER
Robert Pinzinger
Original Assignee
Giesecke & Devrient 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 Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to EP05715929A priority Critical patent/EP1728162A1/de
Publication of WO2005093580A1 publication Critical patent/WO2005093580A1/de

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
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/17—Embedded application
    • G06F2212/177—Smart card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2143—Clearing memory, e.g. to prevent the data from being stolen

Definitions

  • Garbage "garbage CoUection) for smart cards
  • the invention relates to a method for automatic garbage collection, in particular a tracing collector, and a method used to search dynamically allocated heap memory for referenced or non-referenced objects, in particular for computer systems with low system resources (data carriers), such as e.g. Smart cards (chip cards) and a corresponding data carrier.
  • data carriers such as e.g. Smart cards (chip cards) and a corresponding data carrier.
  • a data carrier in particular a smart card, in particular a Java card, typically has a microprocessor, several memories, e.g. ROM, EEPROM and RAM, whereby ROM and / or EEPROM can be partially or completely replaced by flash memory, and one or more interfaces.
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • RAM random access memory
  • a program running on a computer system allocates memory, i.e. Allocates working memory in which the individual program code commands of the program are executed.
  • the working memory can be divided into a statically allocated memory and a dynamically allocated heap memory.
  • the statically allocated memory is allocated before the program is run, e.g. while compiling or linking the program, whereas the dynamically allocated heap memory is allocated during the runtime of the program, i.e. while the program code is running.
  • Statically allocated memory includes - at least in part - the stack memory on which e.g. Variables are created when methods (e.g. algorithms) are called. Such methods can, for example, be methods that deal with automatic garbage collection (see below).
  • Each object can contain one or more references to other objects, which in turn can have references to other objects. Due to the references of objects to other objects, the objects in the heap memory have a tree-like organizational structure (tree structure).
  • tree structure tree-like organizational structure
  • FIG. 1 Such a tree-like organizational structure, which is also called a heap structure, is shown in FIG. 1.
  • the root object is arranged at the root (Root) or in other words at the zero hierarchy level of the organizational structure, that is to say the object with the number one (1) in FIG. 1.
  • Each reference to an object starting from the root object represents the entrance to a branch of the tree structure.
  • six objects 2, 20, 14, 26, 25 and 35 are referenced starting from the root object 1 so that the heap structure has six branches.
  • references objects All objects that are directly or indirectly connected to the root object (called referenced objects) via the tree-like organizational structure can be accessed from the root object.
  • Objects not referenced i.e. Objects that have no connection to the root object via references cannot be reached from the root object.
  • Fig. 1 e.g. objects 31, 32, 33, 29, 30, 23 and 24 not referenced and therefore not accessible from the root object.
  • Each branch of the tree structure has a depth which is equal to the number of levels below the zero hierarchy level (root level) in this branch is. In Fig. 1 e.g. the depth of the
  • Branch from object 1 to object 5 is four, the depth of the branch from object 1 to Object 7 also four, the depth of the branch from object 1 to object 8 three etc.
  • a forward-looking heap structure is organized in such a way that for every given object (for example, an object of an i-th hierarchy level), every object referenced by the given object (consequently an object of the (i + 1) -th hierarchy level ) has a larger index than the specified object of the i-th hierarchy level.
  • a backward reference is characterized by the fact that an object (an i-th hierarchy level) has a higher index than an object referenced by this object (the underlying (i + l) -th hierarchy level).
  • object no. 9 of the second hierarchy level has a higher index than object no. 9 referenced by object no. 9 of the third hierarchy level below.
  • object pairs ((i), (i + 1)) (9, 8), (40, 37), (40, 38), (38, 36), (35, 34) and ( 34, 19) of the referencing object (i) and referenced object (i + 1) each have a backward reference.
  • Heap memory that is no longer used (dynamically allocated working memory) must be released (deallocated) so that heap memory is available again for new objects.
  • the storage space occupied by non-referenced objects can and should be released, since these objects are no longer accessible anyway and are therefore "garbage".
  • a number of object-oriented programming languages for example Java, Smalltalk, Eiffel, Oberon, Perl, Python, Visual Basic and others, have an automatic garbage collection, in which non-referenced objects are recognized and the dynamically allocated heap occupied by them - Memory is automatically released again.
  • the simplest form of automatic garbage collection is the Reference Counting Garbage CoUection or the Reference Counting Collector, in which each object contains a reference counter. The counter reading of the reference counter indicates how many references are directed to the object. The counter reading is incremented by one for each reference to the object generated, and the counter reading is counted down by one for each deleted reference to the object. Objects whose reference counter has a counter reading of zero are classified as garbage and deleted, or the memory space occupied by the garbage objects is allocated to the freely available heap memory.
  • tracing collectors In addition to reference counting collectors, there are tracing collectors in which references are traced from the root class of the heap memory ("traced").
  • the mark-and-sweep collector is the basic algorithm for garbage collections of the Tracing Collector type. With the mark-and-sweep collector, the heap memory is first searched for references in the so-called mark phase, whereby objects to which no references were found are identified and marked. The search for references begins at the root object of the heap memory and works from there hierarchically through the entire heap memory. The objects marked in the mark phase are deleted in the subsequent sweep phase.
  • the heap memory is additionally defragmented during the garbage collection.
  • the referenced objects found ("living" objects) are moved to one end of the heap memory and compacted there. This creates a large contiguous memory area at the opposite end of the heap memory. Then all references to moved objects are updated.
  • the individual branches of the heap structure are successively started, starting from the root object Searched referenced objects, whereby each found referenced object is marked as a referenced (and therefore accessible) object.
  • a corresponding search and marking algorithm is first called for searching and marking for the root object and the root object (object 1 in FIG. 1) is marked.
  • the search and marking algorithm is called recursively for all hierarchy levels below the zero hierarchy level (root level) until the end of the branch is reached.
  • the search for the first branch and marking algorithm called recursively for object 2 of the first hierarchy level, for object 3 of the second hierarchy level, for object 4 of the third hierarchy level and finally for object 5 of the fourth hierarchy level.
  • the sub-branch is searched, which extends from object 2 to object 7, the algorithm being called up recursively again.
  • the branch that extends from object 1 to object 19 is searched.
  • the maximum depth of the tree of FIG. 1 is five and is realized in the branch that extends from object 1 to object 36.
  • Each object in a tree structure requires a single bit, i.e. 1/8 byte, for a flag that indicates whether the object is referenced or not.
  • a tree structure with n objects therefore requires n / 8 bytes of memory (statically allocated working memory) for marking the objects as referenced or not referenced.
  • n / 8 bytes of memory statically allocated working memory
  • variables of a branch that has already been completely searched can be overwritten again when the next branch of the tree structure is searched, since the individual objects of the searched branch are yes are already marked as referenced or not referenced.
  • the depth of the branch of the tree structure with the maximum depth d is relevant for the memory requirement for variables.
  • n: number of objects in the tree structure
  • d: maximum depth of the tree structure
  • v: number of bytes used in the algorithm for local variables (constant per algorithm - Call)
  • rc: memory requirement in bytes.
  • the memory requirement of the recursive search and marking algorithm therefore depends on the maximum depth of the tree structure, which is still unknown until the tree structure has been completely searched. Consequently, the storage requirements of the conventional recursive search and marking algorithm, which e.g. When using conventional mark-and-sweep garbage coUection, do not determine in advance, before searching the tree structure and thus before the runtime of the algorithm.
  • the invention is based on the object of creating a method for automatic garbage collection and a method used for searching dynamically allocated heap memory for referenced or non-referenced objects, in which the memory requirement (memory requirement) for performing the garbage collection in advance, before executing the procedure.
  • objects are created in dynamically allocated heap memory. Objects on the heap memory that can no longer be reached are to be found using the method according to the invention, which systematically searches the heap memory for this purpose. According to independent claim 1, the search of the heap memory is carried out by means of an algorithm which works without recursion.
  • the algorithm is only called once, without being called again within the algorithm in a nested manner.
  • the number of v bytes that the algorithm for local variables requires is determined in advance as required and is therefore known even before the algorithm limit is called. Since the algorithm is called only once, the algorithm for local variables only needs a total of only exactly one time v bytes (instead of maximum depth of the tree structure times v bytes in the conventional recursive method). Therefore, in the method according to the invention, the memory requirement for executing the algorithm is known in advance.
  • a method is created in which the memory requirement (memory requirement), in particular the need for statically allocated or allocable memory (memory) for the method can be determined in advance, before the execution of the method, which is specifically for Systems with limited memory resources, such as Smart cards, is very beneficial.
  • memory requirement memory requirement
  • statically allocated or allocable memory memory
  • Referenced objects found using the algorithm are preferably marked so that the remaining non-referenced objects can be deleted in a subsequent step, e.g. by declaring the space occupied by the non-referenced objects as freely available heap space. Deleting the non-referenced objects or releasing the memory occupied by them can be done in a sweep step, as with the mark-and-sweep procedure. Alternatively, the referenced objects found can be saved, as with the Compacting Collector or the Copying Collector, and the remaining memory can be declared as freely available heap memory. Optionally, the memory is additionally defragmented during the garbage collection.
  • Each object is preferably assigned a unique object index, the object indices of all objects in the heap memory specifying a unique sequence of the objects.
  • the objects of the heap memory are searched in the order of their object indices, regardless of any underlying heap structure.
  • the object index can e.g. be a number or an alphabet letter or a linear address or another index that forms a clear sequence with other numbers, alphabet letters etc.
  • the objects are preferably numbered in the heap memory and are searched in the order in which they are numbered. By numbering everyone Object is assigned a unique object index with which the object can be uniquely addressed. In addition, each object index has a unique successor, so that the object indices of all objects in the heap structure define a unique order of the objects.
  • the heap memory is searched strictly for the object index or numbering of the objects, regardless of whether a branch of the heap structure is searched to the end or not.
  • the heap memory is searched in each
  • Branch of the heap structure according to which the heap memory is organized is carried out to the end of the respective branch before the search for the next branch is started, regardless of the numbering or indexing of the individual objects.
  • the heap memory is free of backward references - or in other words if the heap memory is strictly forward-oriented - it is sufficient to search the memory once in the order of the object indexes or the numbering of the objects, preferably starting with as Start object used root object, for example in an embodiment like that shown in FIG. 3 with the number 1, up to a last object, according to FIG. 3 for example with the number 40. If the root object has the highest number, the search is e.g. Started at the highest number and continued to the object with the lowest number (e.g. one or zero). In this case, found referenced objects are preferably marked, so that the non-referenced objects remain. This can be followed by a cleanup step as described above.
  • Start object used root object for example in an embodiment like that shown in FIG. 3 with the number 1, up to a last object, according to FIG. 3 for example with the number 40.
  • the search is e.g. Started at the highest number and continued to the object with the lowest number (e.g. one or zero). In this
  • a heap memory that is forward-oriented with respect to the object indexes or numbering is searched exactly twice according to the algorithm, the second time of the search being carried out to check that the algorithm limit can be ended. If the heap memory has one or more backward references, ie if the heap memory has at least one pair of referencing object (i) and referenced object (i + 1) with respect to the object indexes or numbering of its objects, which pair have a backward reference (backward-pointing) Reference relationship), the heap memory is preferably searched at least twice.
  • the heap memory is preferably searched in succession at least once forwards and once backwards.
  • a heap memory which has at least one pair of referencing object ((i)) and referenced object ((i + 1)) with respect to the object indices or numbering of its objects, which have a backward reference to one another, is at least three times searches, the last time (e.g. the third time) of the search being performed to check that the algorithm can be ended.
  • Each referenced current object found using the algorithm is preferably marked. It is further preferred that the method is ended as soon as a search of the entire heap memory has been carried out, in which no marking has been carried out. Optionally, after a run in which no marking has been carried out, the search is run again as a test run in order to check whether there are actually no more markings to be made. In both cases, in other words, from the fact that an idle operation has been carried out with no markings, it is recognized that the method can be ended. In the case of a strictly forward-oriented heap memory, the repeated run, ie the test run, is preferably that second pass.
  • the repeated run ie the test run, for example the third run of searching the heap memory
  • the heap memory is searched several times alternately forwards and backwards as required.
  • the algorithm is called up only once each time a search is carried out, so that the memory requirement (need for statically allocated working memory, in particular stack memory) can be determined in advance for the algorithm.
  • the memory requirement seed for statically allocated working memory, in particular stack memory
  • the memory space that the algorithm occupied during the previous run can be overwritten again. Therefore, the memory requirement does not increase with the number of memory search runs performed.
  • backward references in heap memory which require repeated searches of the heap memory, alternately forward and backward, do not lead to an increase in the memory requirement.
  • the marking of an object is carried out in each case using a marking field provided in a memory which, for example, uses a predetermined number of bits or bytes in a memory which is accessible to the algorithm, e.g. in the statically assigned stack memory.
  • the marking field for the current object has a first data field and a second data field, the first data field (valid) being marked if the current (found) object is referenced and the second data field (scanned) being marked , if all referenced objects originating from the current object are marked as referenced by marking the first data field (valid) for these referenced objects.
  • Each data field can be designed as a flag, for example. The flag is switched to mark the object, i.e. set or deleted depending on the implementation.
  • the marking field according to the invention is preferably provided in RAM (Random Access Memory), in contrast to conventional methods for searching a heap memory.
  • a flag is set (switched) in the header of the object, as is schematically illustrated by FIG. 2. Since the header of the object is usually provided in the EEPROM, the conventional flag is also provided in the EEPROM. As a result, the conventional flag is slow and burdensome for the memory resources of a data carrier (smart card, chip module, chip, etc.) in which the method is used (EEPROM can only be overwritten a limited number of times).
  • the method with the preferred marking field according to the invention in RAM therefore has the additional advantage that it is particularly fast, since the writing time of a RAM is significantly shorter than that of an EEPROM.
  • the method with the preferred marking field according to the invention in RAM is particularly gentle on the memory resources of a data carrier to which the method is used.
  • objects found by means of the algorithm are not marked.
  • the algorithm simply skips each such object, possibly until it encounters the object again when the search is repeated.
  • the method is preferably used in a data carrier such as a smart card, in particular a Java card, or an arbitrarily shaped token or in a chip module for installation in a data carrier or other object or in a chip for installation in a chip module or a data carrier etc.
  • the data carrier or the chip module or the chip preferably has a microprocessor and a plurality of memories (ROM, EEPROM, RAM, possibly flash).
  • the algorithm is preferably implemented in the ROM, possibly alternatively in a flash memory.
  • a working memory, in particular a stack memory in the RAM of the data carrier, is statically assigned to the algorithm, the required size of which is different can be calculated before the runtime in the method according to the invention.
  • the marking field is preferably implemented in RAM, preferably in stack memory.
  • FIG. 1 shows a tree-like organized heap structure, on the basis of which the mark phase of a garbage collection method (garbage coUection) according to the prior art is illustrated;
  • FIG. 2 shows a schematic illustration of an object header stored in the EEPROM of a Java Card, in which references to data likewise stored in the EEPROM are stored, according to the prior art;
  • FIG. 3 shows a heap structure organized in a tree-like manner similar to that shown in FIG. 1, on the basis of which the mark phase of a garbage collection method (garbage coUection) according to an embodiment of the invention is illustrated, relating to a first status of the process during the search of the heap memory;
  • FIG. 4 shows a marking field with two data fields “Valid” and “Scanned” for each object of the heap structure shown in FIG. 3, with markings that correspond to the process status shown in FIG. 3;
  • FIG. 5 shows the heap structure from FIG. 3 for a second process status during the search of the heap memory
  • FIG. 6 shows the marking field from FIG. 4, with markings that correspond to the process status shown in FIG. 5;
  • FIG. 7 shows the heap structure from FIG. 3 at a third status during the search of the heap memory;
  • FIG. 8 shows the marking field from FIG. 4 with markings which correspond to the process status shown in FIG. 7.
  • FIG. 3 shows a tree-like organized heap structure, by means of which the search of a heap memory for references, in particular during the mark phase of a garbage collection method (garbage coUection) according to one embodiment of the invention, is illustrated for a first status of the process during the search of heap memory.
  • garbage coUection garbage coUection
  • the heap memory has 40 objects, which are numbered consecutively from 1 to 40, the object with the number "1" being the root object.
  • Two data fields are provided for each object in order to mark the object , namely a "valid" data field and a "scanned” data field.
  • the memory requirement can be determined before the algorithm expires, as shown below.
  • n: number of objects in the tree structure
  • v: number of bytes used in the algorithm for local variables (constant per algorithm call)
  • rc: memory requirement in bytes
  • the term (2 * n + 8) specifies the number of bits (1/8 bytes) required for the "valid" and "scanned" data fields (valid flags and scanned flags) for the n objects in the heap Structure are required.
  • the term v specifies the memory requirement in bytes for local variables and appears only once, since the algorithm is called only once per pass through the search of the heap memory.
  • n ma ⁇ of objects that can be accommodated in a memory of size rc can be determined in advance from equation (2):
  • n be the number of objects in heap memory.
  • an object list be created in which a marking field (shown schematically in FIG. 4) with two data fields is provided for each object, namely a data field for a valid flag and a data field for a scanned flag.
  • the exemplary search and marking algorithm is:
  • the two data fields of the marking field are designed as a valid flag and a scanned flag (cf. FIG. 4).
  • the valid flag of an object is set when the object is referenced.
  • the scanned flag is set when all references originating from this object have been searched.
  • the objects are numbered from 1 to n, whereby the object numbered 1 is the root object (start object).
  • the object list has the shape shown in FIG. 4 and the heap structure has the shape shown in FIG. 3.
  • FIG. 4 shows the assignment of the valid flags and scanned flags of the marking field for the heap structure from FIG. 3 after algorithm 1 has been applied to the heap structure.
  • the heap structure has backward references, which means that not all objects of the heap structure can be checked if only a single pass through the search of the heap is carried out. For example, there is a backward reference between the pair of objects (6, 9).
  • the object 9 of the second hierarchical level has a higher object index than the object 6 of the third hierarchical level. For this reason, when the algorithm 1 proceeds from object 5, which should already be marked as valid and scanned, to object 6, the object 6 is not yet marked as valid. Consequently, the references originating from the object are not scanned, but the algorithm 1 proceeds go straight to object 7, from there to object 8 and on to object 9.
  • Objects 6, 7 and 8 remain unmarked, ie neither the valid flag nor the scanned flag is set. Only object 9 is valid again. Objects 6 and 8 are therefore marked as valid and then object 9 is marked as scanned. The scanned flags of objects 6 and 8 do not remain set (see also FIG. 4). In object 7, the valid flag and the scanned flag are both not set (see FIG. 4).
  • Objects in the heap structure that have backward references can be checked by alternating the heap memory forward as often as required (from 1 to 40 in FIG. 3) and backward (from 40 to FIG. 3) 1) is searched.
  • FIG. 3 shows the heap structure after the heap has been searched forward once by applying algorithm 1 to it
  • FIG. 5 shows the same heap structure after the heap memory has additionally been searched backwards is.
  • 5 shows the heap structure after an algorithm 2 has been applied to it, e.g. the following:
  • Algorithm 2 comprises a forward pass (forward scan) through the heap memory, which essentially corresponds to that of algorithm 1, and a backward pass (backward scan).
  • forward scan forward scan
  • backward pass backward scan
  • the scanned flags were set in particular for objects 6 and 8 that had not yet been set after the forward run.
  • the valid flag was set for object 7 during the reverse run.
  • the flags set in addition to the forward pass during the reverse pass are also shown in FIG. 6, in which the check box of FIG. 4 is shown after a reverse pass has additionally been applied to the heap memory.
  • a binary third data field “end flag” is additionally used, which is switched as soon as a
  • Algorithm 3 searches the heap memory alternately forwards and backwards until a scan scan of the heap memory has been carried out in which no marking has been made. This is realized by the (do, while) loop, which has as a condition for the continuation that the end flag is switched to the boolean value "false". Only if no marking (valid flag) has been made in one run the end flag remains set to the Boolean value "true” and the (do, while) loop and thus the algorithm is ended.
  • FIG. 7 shows the heap structure from FIGS. 1 and 3 after algorithm 3 has been applied to the underlying heap memory
  • FIG. 8 shows the associated object list. All objects in the heap structure are already marked as valid.
  • the state according to FIGS. 7 and 8 is also the state at the start of the last run of the (do, while) loop of the algorithm 3. Since no marking is made on a valid flag during this run, the end flag remains set to true so that the (do, while) loop ends after this last pass.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Die Erfindung schafft ein Verfahren zum Durchsuchen von dynamisch zugewiesenem Heap-Speicher nach referenzierten oder nicht referenzierten Objekten, bei dem ein Durchsuchen des Heap-Speichers mittels eines Algorithmus durchgeführt wird, der ohne Rekursion arbeitet. Das Verfahren ist insbesondere bei der automatischen Speicherbereinigung (Garbage Collection) verwendbar. Für den rekursionfreien Algorithmus ist der Speicherbedarf, um den Algorithmus ausführen zu können, vor der Laufzeit ermittelbar. Daher ist das Verfahren besonders für Rechnersysteme mit begrenzten Speicherressourcen wie z.B. Smart Card geeignet. Angegeben wird auch ein entsprechender Datenträger, insbesondere Smart Card, z.B. Java Card, in dem das Verfahren implementiert ist.

Description

Speicherbereinigung ("Garbage CoUection) für Smart Cards
Die Erfindung betrifft ein Verfahren zur automatischen Speicherbereinigung (Garbage CoUection), insbesondere einen Tracing Collector, und ein dabei verwendetes Verfahren zum Durchsuchen von dynamisch zugewiesenem Heap-Speicher nach referenzierten oder nicht referenzierten Objekten, insbesondere für Rechnersysteme mit geringen Systemressourcen (Datenträger), wie z.B. Smart Cards (Chipkarten), sowie einen entsprechenden Datenträger.
Ein Datenträger, insbesondere Smart Card, insbesondere Java Card, hat typischerweise einen Mikroprozessor, mehrere Speicher, z.B. ROM, EEPROM und RAM, wobei ROM und/oder EEPROM teilweise oder ganz durch Flash- Speicher ersetzt sein können, und ein oder mehrere Schnittstellen.
Ein auf einem Rechnersystem ablaufendes Programm (Computerprogramm) weist sich Arbeitsspeicher zu, d.h. allokiert Arbeitsspeicher, in welchem die einzelnen Programmcode-Befehle des Programms ausgeführt werden.
Der Arbeitsspeicher lässt sich in einen statisch zugewiesenen Speicher und einen dynamisch zugewiesenen Heap-Speicher unterteilen. Der statisch zugewiesene Speicher wird vor dem Ablaufen des Programms zugewiesen, z.B. während des Compi- lierens oder Linkens des Programms, wohingegen der dynamisch zugewiesene Heap- Speicher während der Laufzeit des Programms zugewiesen wird, d.h. während der Programmcode abläuft.
Zum statisch zugewiesenen Speicher zählt - zumindest teilweise - der Stack- Speicher, auf dem z.B. Variablen beim Aufruf von Methoden (z.B. Algorithmen) angelegt werden. Solche Methoden können beispielsweise Methoden sein, die eine automatische Speicherbereinigung zum Gegenstand haben (siehe weiter unten).
Bei objektorientierten Programmiersprachen wie z.B. Java™ von Sun Microsystems wird die dynamische Zuweisung von Arbeitsspeicher während der Laufzeit des Pro- gramms in der Form durchgeführt, dass im Heap-Speicher (bei Java Cards i.d.R. im EEPROM oder ggf. Flash-Speicher) Objekte angelegt werden.
Jedes Objekt kann ein oder mehrere Referenzen auf andere Objekte enthalten, die wiederum Referenzen auf andere Objekte haben können. Durch die Referenzen von Objekten auf andere Objekte haben die Objekte im Heap-Speicher untereinander eine baumartige Organisationsstruktur (Baumstruktur).
Eine solche baumartige Organisationsstruktur, die auch Heap-Struktur genannt wird, ist in Fig. 1 gezeigt. An der Wurzel (Root) oder mit anderen Worten an der nullten Hierarchie-Ebene der Organisationsstruktur ist das Root-Objekt angeordnet, in Fig. 1 also das Objekt mit der Nummer eins (1). Bei anders gestalteten Heap-Strukturen kann es alternativ mehrere Root-Objekte geben, die dann auch als Start-Objekte bezeichnet werden, wobei von jedem Root-Objekt bzw. Start-Objekt aus eine eigene baumartige Organisationsstruktur ausgeht. Jede vom Root-Objekt ausgehende Referenz auf ein Objekt stellt den Eingang zu einem Zweig der Baumstruktur dar. In der Heap-Struktur von Fig. 1 sind ausgehend vom Root-Objekt 1 sechs Objekte 2, 20, 14, 26, 25 und 35 referenziert, so dass die Heap-Struktur sechs Zweige hat. Alle Objekte, die über die baumartige Organisationsstruktur direkt oder indirekt (d.h. über weitere Objekte) mit dem Root-Objekt verbunden sind (referenzierte Objekte genannt), sind vom Root-Objekt aus erreichbar. Nicht referenzierte Objekte, d.h. Objekte, die keine Verbindung über Referenzen zum Root-Objekt haben, sind vom Root-Objekt aus nicht erreichbar. In Fig. 1 sind z.B. die Objekte 31, 32, 33, 29, 30, 23 und 24 nicht referenziert und daher vom Root-Objekt aus nicht erreichbar.
Die Objekte, die vom Root-Objekt aus direkt referenziert sind, bilden die Objekte der ersten Hierarchie-Ebene. Die von Objekten der ersten Hierarchie-Ebene aus referenzierten Objekte bilden Objekte einer zweiten Hierarchie-Ebene usw.. Jeder Zweig der Baumstruktur hat eine Tiefe, die gleich der Anzahl Ebenen unter der nullten Hie- rarchie-Ebene (Root-Ebene) in diesem Zweig ist. In Fig. 1 ist z.B. die Tiefe des
Zweigs von Objekt 1 bis Objekt 5 gleich vier, die Tiefe des Zweigs von Objekt 1 bis Objekt 7 ebenfalls gleich vier, die Tiefe des Zweigs von Objekt 1 bis Objekt 8 gleich drei etc..
Unter Bezugnahme auf Fig. 1 ist eine vorwärtsgerichtete Heap-Struktur derart orga- nisiert, dass zu jedem vorgegebenen Objekt (z.B. Objekt einer i-ten Hierarchieebene) jedes von dem vorgegebenen Objekt referenzierte Objekt (folglich Objekt der (i+1)- ten Hierarchieebene) einen größeren Index hat als das vorgegebene Objekt der i-ten Hierarchieebene. Unter Umständen kann es jedoch vorkommen, dass eine Heap- Struktur mit Rückwärtsreferenzen angelegt wird. Eine Rückwärtsreferenz ist dadurch ausgezeichnet, dass ein Objekt (einer i-ten Hierarchieebene) einen höheren Index hat als ein von diesem Objekt referenziertes Objekt (der darunterliegenden (i+l)-ten Hierarchieebene). In der Heap-Struktur aus Fig. 1 liegt beispielsweise zwischen dem Paar von Objekten (9, 6) eine Rückwärtsreferenz vor. Denn das Objekt Nr. 9 der zweiten Hierarchieebene hat einen höheren Index als das von Objekt Nr. 9 referen- zierte Objekt Nr. 6 der darunterliegenden dritten Hierarchieebene. Ebenso liegt zwischen den Objekt-Paaren ((i), (i+1)) = (9, 8), (40, 37), (40, 38), (38, 36), (35, 34) und (34, 19) von referenzierendem Objekt (i) und referenziertem Objekt (i+1) jeweils eine Rückwärtsreferenz vor.
Nicht mehr verwendeter Heap-Speicher (dynamisch zugewiesener Arbeitsspeicher) muss wieder freigegeben (deallokiert) werden, damit für neue Objekte wieder Heap- Speicher zur Verfügung steht. Bei objektorientierten Programmiersprachen kann und soll also insbesondere der durch nicht referenzierte Objekte belegte Speicherplatz freigegeben werden, da diese Objekte ohnehin nicht mehr erreichbar sind und somit "Garbage" (Müll) sind.
Eine Reihe von objektorientierten Programmiersprachen, beispielsweise Java, Smalltalk, Eiffel, Oberon, Perl, Python, Visual Basic und weitere, haben eine automatische Speicherbereinigung (Garbage CoUection), bei der nicht referenzierte Ob- jekte erkannt werden und der durch sie belegte dynamisch zugewiesene Heap- Speicher automatisch wieder freigegeben wird. Die einfachste Form der automatischen Speicherbereinigung ist die Reference Coun- ting Garbage CoUection oder der Reference Counting Collector, bei dem jedes Objekt einen Referenzzähler enthält. Der Zählerstand des Referenzzählers gibt an, wie viele Referenzen auf das Objekt gerichtet sind. Für jede erzeugte Referenz auf das Objekt wird der Zählerstand um eins hochgezählt, und für jede gelöschte Referenz auf das Objekt wird der Zählerstand um eins heruntergezählt. Objekte, deren Referenzzähler einen Zählerstand von Null hat, werden als Garbage eingestuft und gelöscht bzw. der von den Garbage-Objekten besetzte Speicherplatz wird dem frei ver- fügbaren Heap-Speicher zugewiesen.
Neben Reference Counting Collectors gibt es die Tracing Collectors, bei denen Referenzen von der Root-Klasse (Wurzelklasse) des Heap- Speichers aus verfolgt ("getra- cet") werden.
Bei den Speicherbereinigungen (Garbage Collections) vom Typ Tracing Collector bildet der Mark-and-Sweep Collector den grundlegenden Algorithmus. Beim Mark- and-Sweep Collector wird zuerst, in der sogenannten Mark-Phase, der Heap-Speicher nach Referenzen durchsucht, wobei Objekte, auf die keine Referenzen gefunden wurden, identifiziert und markiert werden. Die Suche nach Referenzen beginnt dabei am Root-Objekt des Heap-Speichers und arbeitet sich von dort aus hierarchisch durch den gesamten Heap-Speicher durch. Die in der Mark-Phase markierten Objekte werden in der nachfolgenden Sweep-Phase gelöscht.
Bei zwei weiteren Formen von automatischer Speicherbereinigung (Garbage CoUection) vom Typ Tracing Collector, den Compacting Collectors und den Copying Collectors, wird der Heap-Speicher bei der Speicherbereinigung zusätzlich defragmentiert.
Sowohl Compacting Collectors als auch Copying Collectors beginnen mit einem
Durchsuchen des Heap-Speichers nach Referenzen, nur dass hier nicht die nicht refe- renzierten "toten" Objekte gesucht werden, sondern die "lebenden" Objekte, auf die noch Referenzen gerichtet sind (referenzierte Objekte).
Bei Compacting Collectors werden die gefundenen referenzierten Objekte ("leben- den" Objekte) zu einem Ende des Heap-Speichers hin verschoben und dort kompak- tiert. Dadurch entsteht am entgegengesetzten Ende des Heap-Speichers ein großer zusammenhängender Speicherbereich. Anschließend werden alle Referenzen auf verschobene Objekte aktualisiert.
Bei Copying Collectors werden alle gefundenen referenzierten ("lebenden") Objekte von ihrem bisherigen alten Speicherbereich in einen neuen Speicherbereich kopiert und dabei lückenlos aneinandergefügt. Dadurch ist der neue Speicherbereich zusammenhängend, also defragmentiert. Der alte Speicherbereich wird als frei verfügbarer Speicherbereich deklariert.
Bislang sind Verfahren zur automatischen Speicherbereinigung - mit Ausnahmen - überwiegend auf ausgedehnte Rechnersysteme beschränkt. Bei Rechnersystemen mit geringen Systemressourcen wie z.B. Smart Cards reicht häufig der Arbeitspeicher für eine automatische Speicherbereinigung nicht aus.
Bei dem gängigen, in Fig. 1 veranschaulichten Verfahren zum Durchsuchen des Heap-Speichers nach referenzierten Objekten, das bei der Mark-and-Sweep Garbage CoUection verwendet wird, werden, ausgehend vom Root-Objekt, die einzelnen Zweige der Heap-Struktur nacheinander nach referenzierten Objekten durchsucht, wobei jedes aufgefundene referenzierte Objekt als referenziertes (und daher erreichbares) Objekt markiert wird. Gemäß Fig. 1 wird zum Durchsuchen und Markieren zuerst für das Root-Objekt ein entsprechender Such- und Markier- Algorithmus aufgerufen und das Root-Objekt (in Fig. 1 Objekt 1) markiert. Anschließend wird, nacheinander für jeden Zweig, der Such- und Markier- Algorithmus rekursiv für alle Hie- rarchie-Ebenen unterhalb der nullten Hierarchie-Ebene (Root-Ebene) aufgerufen, bis das Ende des Zweigs erreicht ist. In Fig. 1 wird z.B. für den ersten Zweig der Such- und Markier- Algorithmus rekursiv aufgerufen für das Objekt 2 der ersten Hierarchie- Ebene, für das Objekt 3 der zweiten Hierarchie-Ebene, für das Objekt 4 der dritten Hierarchie-Ebene und schließlich für das Objekt 5 der vierten Hierarchie-Ebene. Anschließend wird, im Beispiel von Fig. 1, der Teilzweig durchsucht, der sich von Ob- jekt 2 bis Objekt 7 erstreckt, wobei der Algorithmus wieder rekursiv aufgerufen wird. Zu letzt wird, im Beispiel von Fig. 1, der Zweig durchsucht, der sich von Objekt 1 bis Objekt 19 erstreckt. Die maximale Tiefe des Baums aus Fig. 1 ist gleich fünf und ist in dem Zweig verwirklicht, der sich von Objekt 1 bis Objekt 36 erstreckt.
Im Beispiel aus Fig. 1 sind die Objekte 31, 32, 33, 29, 30, 23 und 24 nicht referenziert und daher „Müll" (garbage).
Der Speicherbedarf für einen rekursiven Algorithmus wie den obenstehend beschrie- benen, bei dem der Algorithmus innerhalb des Algorithmus immer wieder erneut aufgerufen wird, lässt sich nicht im Voraus ermitteln, wie nachfolgend dargelegt ist. Dies ist einer der Gründe, warum der herkömmliche rekursive Algorithmus in der Regel nicht ohne Weiteres auf ein Rechnersystem mit geringen Systemressourcen wie z.B. eine Smart Card übertragbar ist.
Jedes Objekt in einer Baumstruktur benötigt ein einzelnes Bit, also 1/8 Byte, für ein Flag, mit dem gekennzeichnet wird, ob das Objekt referenziert ist oder nicht. Eine Baumstruktur mit n Objekten benötigt somit n/8 Byte Speicher (statisch allozierten Arbeitsspeicher) für die Markierung der Objekte als referenziert oder nicht referen- ziert. Bei der Anwendung des Such- und Markier- Algorithmus auf einen Zweig der Baumstruktur wird für jeden Aufruf des Algorithmus und damit für jede Hierarchie- Ebene eine Anzahl von v Bytes für lokale Variablen verwendet. Für einen Zweig der Tiefe d' wird daher ein Anzahl von d' * v Bytes an Speicher für Variablen benötigt. Zu berücksichtigen ist hierbei, dass die Variablen eines bereits vollständig durch- suchten Zweigs wieder überschrieben werden können, wenn der nächste Zweig der Baumstruktur durchsucht wird, da die einzelnen Objekte des durchsuchten Zweig ja bereits als referenziert oder nicht referenziert markiert sind. Relevant für den Speicherbedarf für Variablen ist somit die Tiefe des Zweigs der Baumstruktur mit der maximalen Tiefe d.
Sei also für eine Baumstruktur wie die in Fig. 1 dargestellte n := Anzahl der Objekte in der Baumstruktur d := maximale Tiefe der Baumstruktur v := Anzahl von Bytes, die bei dem Algorithmus für lokale Variablen ver- wendet werden (konstant pro Algorithmus- Aufruf) rc:= Speicherbedarf in Byte.
Dann gilt für den Speicherbedarf rc des Algorithmus in Byte, rc - n / 8 + d * v (1)
Der Speicherbedarf des rekursiven Such- und Markier- Algorithmus hängt also von der maximalen Tiefe der Baumstruktur ab, die noch unbekannt ist, solange die Baumstruktur nicht vollständig durchsucht worden ist. Folglich lässt sich der Spei- cherbedarf des herkömmlichen rekursiven Such- und Markier- Algorithmus, der z.B. bei der herkömmlichen Mark-and-Sweep Garbage CoUection verwendet wird, nicht im Voraus, vor dem Durchsuchen der Baumstruktur und damit vor der Laufzeit des Algorithmus, ermitteln.
Bei Rechnersystemen mit großzügig bemessenen Systemressourcen (Speicher und/ oder Rechenleistung) wie z.B. PCs, Workstations oder Servern wird einem rekursiven Such- und Markier- Algorithmus im Zweifelsfall überreichlich Arbeitsspeicher, insbesondere Stack-Speicher, zugewiesen.
Vor allem für Rechnersysteme mit geringen Systemressourcen, wie z.B. Smart
Cards, reicht der insgesamt verfügbare Speicher unter Umständen nicht aus, um im Zweifelsfall überreichlich Arbeitsspeicher zuzuweisen. Daher ist es wünschenswert, den Speicherbedarf eines Algorithmus für die automatische Speicherbereinigung im Voraus zu kennen, um zu ermitteln, ob der Algorithmus auf dem Rechnersystem überhaupt lauffähig ist, d.h. ausgeführt werden kann, und um zu verhindern, dass der Arbeitsspeicher überläuft und in Folge beim Ausführen des Algorithmus Fehler im Programmablauf auf reten.
Ausgehend hiervon liegt der Erfindung die Aufgabe zu Grunde, ein Verfahren zur automatischen Speicherbereinigung (Garbage CoUection) und ein dabei verwendetes Verfahren zum Durchsuchen von dynamisch zugewiesenem Heap-Speicher nach referenzierten oder nicht referenzierten Objekten zu schaffen, bei dem der Speicherbedarf (Bedarf an Arbeitsspeicher) für die Durchführung der Speicherbereinigung im Voraus, vor der Ausführung des Verfahrens, ermittelbar ist.
Die Aufgabe wird gelöst durch ein Verfahren nach dem unabhängigen Verfahrensanspruch. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Bei dem erfindungsgemäßen Verfahren gemäß Anspruch 1 sind in dynamisch zuge- wiesenem Heap-Speicher Objekte angelegt. Nicht mehr erreichbare Objekte auf dem Heap-Speicher sollen mittels des erfindungsgemäßen Verfahrens gefunden werden, das hierzu den Heap-Speicher systematisch durchsucht. Gemäß dem unabhängigen Anspruch 1 wird das Durchsuchen des Heap-Speichers mittels eines Algorithmus durchgeführt, der ohne Rekursion arbeitet.
Dadurch, dass keine Rekursion durchgeführt wird, wird der Algorithmus nur ein einziges Mal aufgerufen, ohne dass er innerhalb des Algorithmus geschachtelt erneut aufgerufen wird. Die Anzahl v Bytes, die der Algorithmus für lokale Variablen benötigt, wird im Voraus nach Bedarf festgelegt und ist folglich bereits vor dem Aufru- fen des Algoritlimus bekannt. Da der Algorithmus nur ein einziges Mal aufgerufen wird, benötigt der Algorithmus für lokale Variablen insgesamt eine Anzahl von nur genau ein Mal v Bytes (statt maximale Tiefe der Baumstruktur Mal v Bytes beim herkömmlichen rekursiven Verfahren). Daher ist bei dem erfindungsgemäßen Verfahren der Speicherbedarf zur Ausführung des Algorithmus im Voraus bekannt.
Daher ist gemäß Anspruch 1 ein Verfahren geschaffen, bei dem der Speicherbedarf (Bedarf an Arbeitsspeicher), insbesondere der Bedarf an statisch zugewiesenem oder zuzuweisendem Speicher (Arbeitsspeicher) für das Verfahren, im Voraus, vor der Ausführung des Verfahrens, ermittelbar ist, was speziell für Systeme mit begrenzten Speicherressourcen, wie z.B. Smart Cards, sehr vorteilhaft ist.
Mittels des Algorithmus gefundene referenzierte Objekte werden vorzugsweise markiert, damit in einem nachfolgenden Schritt die übrig gebliebenen nicht referenzierten Objekte gelöscht werden können, z.B. indem der von den nicht referenzierten Objekten belegte Speicherplatz als frei verfügbarer Heap-Speicherplatz deklariert wird. Das Löschen der nicht referenzierten Objekte bzw. Freigeben des durch sie belegten Speichers kann in einem Sweep-Schritt wie beim Mark-and-Sweep Verfahren erfolgen. Alternativ können die gefundenen referenzierten Objekte gerettet werden, wie beim Compacting Collector oder beim Copying Collector, und der übrig bleibende Speicher als frei verfügbarer Heap-Speicher deklariert werden. Wahlweise wird der Speicher bei der Speicherbereinigung zusätzlich defragmentiert.
Vorzugsweise ist jedem Objekt ein eindeutiger Objektindex zugewiesen, wobei durch die Objektindizes aller Objekte des Heap-Speichers eine eindeutige Reihenfolge der Objekte festgelegt ist. Gemäß dem Algorithmus werden die Objekte des Heap- Speichers in der Reihenfolge ihrer Objektindizes abgesucht, unabhängig von einer ggf. zu Grunde liegenden Heap-Struktur. Der Objektindex kann z.B. eine Zahl oder ein Alphabetbuchstabe oder eine lineare Adresse sein oder ein sonstiger Index, der mit weiteren Zahlen, Alphabetbuchstaben etc. eine eindeutige Reihenfolge bildet.
Vorzugsweise sind die Objekte in dem Heap-Speicher nummeriert und werden in der Reihenfolge ihrer Nummerierung abgesucht. Durch die Nummerierung ist jedem Objekt ein eindeutiger Objektindex zugewiesen, mit dem das Objekt eindeutig adressierbar ist. Zusätzlich hat jeder Objektindex einen eindeutigen Nachfolger, so dass durch die Objektindizes aller Objekte der Heap-Struktur eine eindeutige Reihenfolge der Objekte festgelegt ist.
Beim Algorithmus mit Objekten mit Objektindex bzw. Nummerierung wird das Durchsuchen des Heap-Speichers streng nach dem Objektindex bzw. der Nummerierung der Objekte durchgeführt, unabhängig davon, ob ein Zweig der Heap-Struktur bis zum Ende durchsucht ist oder nicht. Beim üblicherweise verwendeten herkömm- liehen Algorithmus wird dagegen das Durchsuchen des Heap-Speichers in jedem
Zweig der Heap-Struktur, gemäß der der Heap-Speicher organisiert ist, bis zum Ende des jeweiligen Zweigs durchgeführt, bevor mit dem Durchsuchen des nächsten Zweiges begonnen wird, unabhängig von einer Nummerierung bzw. Indizierung der einzelnen Objekte.
Sofern der Heap-Speicher frei von Rückwärtsreferenzen ist - oder mit anderen Worten sofern der Heap-Speicher streng vorwärtsgerichtet ist - , genügt es, den Speicher ein einziges Mal in der Reihenfolge der Objektindizes bzw. der Nummerierung der Objekte zu durchsuchen, vorzugsweise beginnend beim als Start-Objekt verwendeten Root-Objekt, bei einer Ausführungsform wie der in Fig. 3 gezeigten z.B. mit der Nummer 1, bis zu einem letzten Objekt, gemäß Fig. 3 beispielsweise mit der Nummer 40. Falls das Root-Objekt die höchste Nummer hat, wird das Durchsuchen z.B. bei der höchsten Nummer begonnen und bis zum Objekt mit der niedrigsten Nummer (z.B. Eins oder Null) durchgeführt. Gefundene referenzierte Objekte werden in diesem Fall vorzugsweise markiert, so dass die nicht referenzierten Objekte übrig bleiben. Nachfolgend kann wie oben beschrieben ein Bereinigungsschritt folgen.
Alternativ wird ein Heap-Speicher, der bezüglich der Objektindizes bzw. Nummerierung vorwärtsgerichtet ist, gemäß dem Algorithmus genau zwei Mal durchsucht, wobei das zweite Mal des Durchsuchens zur Überprüfung durchgeführt wird, dass der Algoritlimus beendet werden kann. Sofern der Heap-Speicher eine oder mehrere Rückwärtsreferenzen aufweist, d.h. falls der Heap-Speicher bezüglich der Objektindizes bzw. Nummerierung seiner Objekte mindestens ein Paar von referenzierendem Objekt (i) und referenzierten Objekt (i+1) aufweist, die zueinander eine Rückwärtsreferenz (rückwärtsgerichtete Referenz- Beziehung) haben, wird vorzugsweise der Heap-Speicher mindestens zwei Mal durchsucht.
Vorzugsweise wird der Heap-Speicher im Fall, dass er mindestens eine Rückwärtsre- ferenz hat, hintereinander mindestens ein Mal vorwärts und ein Mal rückwärts durchsucht.
Alternativ wird ein Heap-Speicher, der bezüglich der Objektindizes bzw. Nummerierung seiner Objekte mindestens ein Paar von referenzierendem Objekt ((i)) und refe- renzierten Objekt ((i+1)) aufweist, die zueinander eine Rückwärtsreferenz haben, mindestens drei Mal durchsucht, wobei das letzte Mal (z.B. das dritte Mal) des Durchsuchens zur Überprüfung durchgeführt wird, dass der Algorithmus beendet werden kann.
Jedes mittels des Algorithmus gefundene referenzierte aktuelle Objekt (aktuelles Objekt im Unterschied zu Objekten, die durch dieses aktuelle Objekt referenziert sind) wird vorzugsweise markiert. Dabei ist es weiter bevorzugt, dass das Verfahren beendet wird, sobald ein Durchlauf des Durchsuchens des gesamten Heap-Speichers durchgeführt worden ist, bei dem keine Markierung vorgenommen worden ist. Wahlweise wird nach einem Durchlauf, bei dem keine Markierung vorgenommen worden ist, ein nochmaliger Durchlauf des Durchsuchens als Prüfdurchlauf vorgenommen, um zu überprüfen, ob tatsächlich keine Markierungen mehr vorzunehmen sind. In beiden Fällen wird mit anderen Worten daran, dass ein Leerlauf durchgeführt worden ist, bei dem keine Markierungen vorgenommen worden sind, erkannt, dass das Verfahren beendet werden kann. Bei einem streng vorwärts gerichteten Heap- Speicher ist der nochmalige Durchlauf, d.h. der Prüfdurchlauf, vorzugsweise der zweite Durchlauf. Bei einem Heap-Speicher mit mindestens einer Rückwärtsreferenz ist der nochmalige Durchlauf, d.h. der Prüfdurchlauf, beispielsweise der dritte Durchlauf des Durchsuchens des Heap-Speichers, allgemeiner der letzte Durchlauf. Dabei wird der Heap-Speicher je nach Bedarf mehrmals abwechselnd vorwärts und rückwärts durchsucht. Bei jedem Durchsuchen wird der Algorithmus nur ein einziges Mal aufgerufen, so dass der Speicherbedarf (Bedarf an statisch zugewiesenem Arbeitsspeicher, insbesondere Stack-Speicher) für den Algorithmus im Voraus ermittelbar ist. Bei jedem erneuten Durchlauf des Durchsuchens kann der Speicherplatz, den der Algorithmus beim vorangehenden Durchlauf belegt hat, wieder überschrie- ben werden. Daher erhöht sich der Speicherbedarf nicht mit der Anzahl von durchgeführten Durchläufen des Durchsuchens des Speichers. Insbesondere führen Rückwärtsreferenzen im Heap-Speicher, die ein mehrmaliges Durchsuchen des Heap- Speichers, abwechselnd vorwärts und rückwärts, erforderlich machen, nicht zu einer Erhöhung des Speicherbedarfs.
Weiter vorzugsweise wird das Markieren eines Objekts jeweils unter Verwendung eines in einem Speicher vorgesehenen Markierungsfeldes durchgeführt, das beispielsweise eine vorbestimmte Anzahl von Bits oder Bytes in einem Speicher benutzt, der für den Algorithmus zugänglich ist, z.B. im statisch zugewiesenem Stack- Speicher.
Gemäß einer bevorzugten Ausführungsform weist das Markierungsfeld für das aktuelle Objekt ein erstes Datenfeld und ein zweites Datenfeld auf, wobei das erste Datenfeld (valid) markiert wird, falls das aktuelle (gefundene) Objekt referenziert ist, und wobei das zweite Datenfeld (scanned) markiert wird, falls alle von dem aktuellen Objekt ausgehenden referenzierten Objekte dadurch als referenziert markiert sind, dass bei diesen referenzierten Objekten das erste Datenfeld (valid) markiert ist. Jedes Datenfeld kann z.B. als ein Flag ausgebildet sein. Das Flag wird zum Markieren des Objekts geschaltet, also je nach Implementierung gesetzt oder gelöscht. Das Markierungsfeld gemäß der Erfindung ist vorzugsweise, anders als bei herkömmlichen Verfahren zum Durchsuchen eines Heap-Speichers, im RAM (Random Access Memory) vorgesehen. Bei herkömmlichen Verfahren zum Durchsuchen eines Heap-Speichers wird, um ein Objekt als referenziert zu markieren, ein Flag im Hea- der des Objekts gesetzt (geschaltet), wie durch Fig. 2 schematisch veranschaulicht ist. Da der Header des Objekts herkömmlicherweise in der Regel im EEPROM vorgesehen ist, ist auch das herkömmliche Flag im EEPROM vorgesehen. Hierdurch ist das herkömmliche Flag langsam und belastend für die Speicherressourcen eines Datenträgers (Smart Card, Chipmodul, Chip etc.), bei dem das Verfahren angewendet wird (EEPROM kann nur eine begrenzte Anzahl von Malen überschrieben werden). Das Verfahren mit dem bevorzugten erfindungsgemäßen Markierungsfeld im RAM hat daher den zusätzlichen Vorteil, dass es besonders schnell ist, da die Schreibzeit eines RAM deutlich niedriger ist als die eines EEPROM. Zudem ist das Verfahren mit dem bevorzugten erfindungsgemäßen Markierungsfeld im RAM besonders scho- nend für die Speicherressourcen eines Datenträgers, bei dem das Verfahren angewendet wird.
Weiter vorzugsweise werden mittels des Algorithmus gefundene Objekte, auf die keine oder noch keine Referenz gefunden wurde, nicht markiert. Der Algorithmus übergeht jedes solche Objekt einfach, ggf. bis er bei einem erneuten Such-Durchlauf erneut auf das Objekt trifft.
Das Verfahren wird vorzugsweise in einem Datenträger wie einer Smart Card, insbesondere einer Java Card, oder einem beliebig geformten Token verwendet oder in einem Chipmodul zum Einbau in einen Datenträger oder sonstigen Gegenstand bzw. in einem Chip zum Einbau in ein Chipmodul oder einen Datenträger etc. Der Datenträger bzw. das Chipmodul bzw. der Chip weist vorzugsweise einen Mikroprozessor und mehrere Speicher (ROM, EEPROM, RAM, ggf. Flash) auf. Der Algorithmus ist vorzugsweise im ROM, ggf. alternativ in einem Flash- Speicher, implementiert. Dem Algorithmus ist vorzugsweise ein Arbeitsspeicher, insbesondere ein Stack-Speicher im RAM des Datenträgers, statisch zugewiesenen, dessen erforderliche Größe sich bei dem erfindungsgemäßen Verfahren vor der Laufzeit berechnen lässt. Das Markierungsfeld ist vorzugsweise im RAM implementiert, vorzugsweise im Stack-Speicher.
Im Folgenden wird die Erfindung anhand von Ausführungsbeispielen und unter Be- zugnahme auf die Zeichnung näher erläutert, in der zeigen:
Fig. 1 eine baumartig organisierte Heap-Struktur, anhand der die Mark-Phase eines Speicherbereinigungsverfahrens (Garbage CoUection) nach dem Stand der Technik veranschaulicht ist;
Fig. 2 eine schematische Darstellung eines im EEPROM einer Java Card abgespeicherten Objekt-Headers, in dem Referenzen auf ebenfalls im EEPROM abgespeicherte Daten abgespeichert sind, gemäß dem Stand der Technik;
Fig. 3 eine zu der in Fig. 1 gezeigten analoge baumartig organisierte Heap-Struktur, anhand der die Mark-Phase eines Speicherbereinigungsverfahrens (Garbage CoUection) gemäß einer Ausfuhrungsform der Erfindung veranschaulicht ist, zu einem ersten Verfahrensstand während des Durchsuchens des Heap- Speichers;
Fig. 4 ein Markierungsfeld mit zwei Datenfeldern „Valid" und „Scanned" für jedes Objekt der in Fig. 3 gezeigten Heap-Struktur, mit Markierungen, die dem in Fig. 3 gezeigten Verfahrensstand entsprechen;
Fig. 5 die Heap-Struktur aus Fig. 3 zu einem zweiten Verfahrensstand während des Durchsuchens des Heap-Speichers;
Fig. 6 das Markierungsfeld aus Fig. 4, mit Markierungen, die dem in Fig. 5 gezeigten Verfahrensstand entsprechen; Fig. 7 die Heap-Struktur aus Fig. 3 zu einem dritten Verfahrensstand während des Durchsuchens des Heap-Speichers;
Fig. 8 das Markierungsfeld aus Fig. 4, mit Markierungen, die dem in Fig. 7 gezeig- ten Verfahrensstand entsprechen.
Fig. 3 zeigt eine baumartig organisierte Heap-Struktur, anhand der das Durchsuchen eines Heap-Speichers nach Referenzen, insbesondere bei der Mark-Phase eines Speicherbereinigungsverfahrens (Garbage CoUection), gemäß einer Ausführungsform der Erfindung veranschaulicht ist, zu einem ersten Verfahrensstand während des Durchsuchens des Heap-Speichers.
Der Heap-Speicher weist 40 Objekte auf, die fortlaufend von 1 bis 40 durchnumme- riert sind, wobei das Objekt mit der Nummer „1" das Root-Objekt ist. Für jedes Ob- jekt sind zwei Datenfelder vorgesehen, um das Objekt zu markieren, nämlich ein „valid"-Datenfeld und ein „scanned"-Datenfeld.
Beim Algorithmus gemäß der bevorzugten Ausführungsform, bei dem die Objekte in der Reihenfolge ihrer Nummerierung abgesucht werden, lässt sich der Speicherbe- darf vor Ablauf des Algorithmus ermitteln, wie nachfolgend gezeigt ist.
Sei also für eine Baumstruktur wie die in Fig. 3 dargestellte n := Anzahl der Objekte in der Baumstruktur v := Anzahl von Bytes, die bei dem Algorithmus für lokale Variablen verwendet werden (konstant pro Algorithmus- Aufruf) rc:= Speicherbedarf in Byte.
Dann gilt für den Speicherbedarf rc des bevorzugten erfindungsgemäßen Algorith- mus in Byte, rc = (2 * n + 8) / 8 + v (2)
Dabei gibt der Term (2*n + 8) die Anzahl Bits (1/8 Bytes) an, die für die „valid"- und „scanned"-Datenfelder (valid-Flags und scanned-Flags) für die n Objekte der Heap-Struktur erforderlich sind. Der Term v gibt den Speicherbedarf in Bytes für lokale Variablen an und erscheint nur ein einziges Mal, da der Algorithmus pro Durchlauf des Durchsuchens des Heap-Speichers nur ein einziges Mal aufgerufen wird.
Aus Gleichung (2) lässt sich die Höchstzahl nmaχ von Objekten im Voraus ermitteln, die sich in einem Speicher der Größe rc unterbringen lassen:
Figure imgf000018_0001
Nachfolgend ist ein beispielhafter rekursionsfreier Algorithmus 1 angeführt, in dem das erfindungsgemäße Verfahren zum Durchsuchen eines Heap-Speichers und zum Markieren gefundener referenzierter Objekte implementiert ist. Sei n die Anzahl von Objekten im Heap-Speicher. Sei zudem eine Objektliste angelegt, in der zu jedem Objekt ein Markierungsfeld (schematisch in Fig. 4 dargestellt) mit zwei Datenfeldern vorgesehen sind, nämlich einem Datenfeld für ein valid-Flag und einem Datenfeld für ein scanned-Flag. Dann lautet der beispielhafte Such- und Markieralgorithmus:
markValidObjekts (int rootObjectlndex, int numberOfObjects)
{ // reset all flags (valid and scanned) (alle Flags zurücksetzen (valid und. scanned)) resetFlags(); // mark root object as valid (Root-Objekt als valid markieren) setValid(rootObjectIndex); .11 scan all objects (alle Objekte scannen(absuchen)) for (i=l; i <= numberOfObjects; i++) { // is valid flag of object i set and scanned flag not yet set? // (ist valid-Flag des Objekts i gesetzt und das scanned Flag noch nicht?) if ( isValid(i) && üsScanned(i)) { // mark all referenced objects of i as valid // (alle durch Objekt i referenzierten Objekte als valid markieren) for (j=0; j < object ist[i].numberOfReferences(); j++) { // mark referenced object j as valid // (referenziertes Objekt j als valid markieren) setValid(objectList[i].getReferenceIndex(j)); } // all references of object i are scanned => set scanned flag of object i // (alle Referenzen von Objekt i sind angescannt worden => // => scanned Flag des Objekts i setzen) setScanned(i); }
(Algorithmus 1)
Bei dem vorangehenden Algorithmus 1 sind die beiden Datenfelder des Markierungsfeldes als ein valid-Flag und ein scanned-Flag ausgeführt (vgl. Fig. 4). Das valid-Flag eines Objekts ist jeweils dann gesetzt, wenn das Objekt referenziert ist. Das scanned-Flag ist jeweils dann gesetzt, wenn alle von diesem Objekt ausgehenden Referenzen abgesucht worden sind. Die Objekte sind von 1 bis n nummeriert, wobei das mit 1 nummerierte Objekt das Root-Objekt (Start-Objekt) ist. Nach Durchlauf des Algorithmus hat die Objektliste die in Fig. 4 dargestellte Gestalt und die Heap- Struktur die in Fig. 3 dargestellte Gestalt.
Das Root-Objekt (i=l) gilt in jedem Fall als referenziert und wird zu Begirm als valid gesetzt. Wahlweise kann es mehrere Root-Objekte geben. In diesem Fall werden zu Beginn alle Root-Objekte als valid gesetzt. Anschließend werden, in der "-Schleife, alle durch das Root-Objekt referenzierten Objekte als valid gesetzt, um zu markieren, dass diese Objekte referenziert sind.
Nachfolgend wird das scanned-Flag des Root-Objekts (i=l) gesetzt, um zu markie- ren, dass alle vom Root-Objekt ausgehenden Referenzen abgescannt (abgesucht) worden sind.
Nun schreitet der Algorithmus 1 vom Root-Objekt (i=l, d.h. Objektindex 1) zum Objekt mit dem nächsthöheren Objektindex fort, d.h. zum Objekt Nr. 2, und prüft, ob das Objekt Nr. 2 valid ist, d.h. ob sein valid-Flag gesetzt ist. Falls das valid-Flag von Objekt Nr. 2 (abweichend von Fig. 3) nicht gesetzt ist, schreitet der Algorithmus 1 unmittelbar weiter zu Objekt 3. Falls hingegen (wie in Fig. 3) das valid-Flag von Objekt Nr. 2 gesetzt ist, werden alle vom Objekt 2 abgehenden Referenzen abgesucht und die von Objekt 2 aus referenzierten Objekte als valid markiert. Schließlich wird das scanned-Flag des Objekts 2 gesetzt, und anschließend schreitet der Algorithmus 1 weiter zu Objekt 3.
Das Verfahren wird bis zum letzten Objekt des Heaps (bei Fig. 3 Objekt 40) durchgeführt. Fig. 4 zeigt die Belegung der valid-Flags und scanned-Flags des Markie- rungsfeldes für die Heap-Struktur aus Fig. 3, nachdem Algorithmus 1 auf die Heap- Struktur angewandt worden ist.
Beim Beispiel aus Fig. 3 hat die Heap-Struktur Rückwärtsreferenzen, die bewirken, dass nicht alle Objekte der Heap-Struktur überprüft werden können, falls nur ein einziger Durchlauf des Durchsuchens des Heaps durchgeführt wird. Beispielsweise besteht zwischen dem Paar von Objekten (6, 9) eine Rückwärtsreferenz. Anders gesagt hat das Objekt 9 der zweiten Hierarchieebene einen höheren Objektindex als das Objekt 6 der dritten Hierarchieebene. Aus diesem Grund ist, wenn der Algorithmus 1 von Objekt 5, das bereits als valid und scanned markiert sein soll, zu Objekt 6 fort- schreitet, das Objekt 6 noch nicht als valid markiert. Folglich werden die von Objekt ausgehenden Referenzen nicht abgescannt, sondern der Algorithmus 1 schreitet di- rekt fort zu Objekt 7, von dort zu Objekt 8 und weiter zu Objekt 9. Objekte 6, 7 und 8 bleiben unmarkiert, d.h. weder das valid-Flag noch das scanned-Flag wird gesetzt. Erst Objekt 9 ist wieder valid. Daher werden Objekte 6 und 8 als valid markiert und anschließend Objekt 9 als scanned markiert. Die scanned-Flags der Objekte 6 und 8 bleiben nicht gesetzt (vgl. auch Fig. 4). Bei Objekt 7 bleiben das valid-Flag und das scanned-Flag beide nicht gesetzt (s. Fig. 4).
Objekte in der Heap-Struktur, bei denen Rückwärtsreferenzen vorliegen, können dadurch überprüft werden, dass der Heap-Speicher so oft wie erforderlich abwech- selnd vorwärts (bei Fig. 3 von 1 bis 40) und rückwärts (bei Fig. 3 von 40 nach 1) durchsucht wird.
Während Fig. 3 die Heap-Struktur zeigt, nachdem der Heap-Speicher ein Mal vorwärts durchsucht worden ist, indem Algorithmus 1 darauf angewandet worden ist, zeigt Fig. 5 dieselbe Heap-Struktur, nachdem der Heap-Speicher zusätzlich ein Mal rückwärts durchsucht worden ist. Fig. 5 zeigt also die Heap-Struktur, nachdem ein Algorithmus 2 darauf angewendet worden ist, wie z.B. der folgende:
markValidObjekts (int rootObjectlndex, int numberOfObjects) { // reset all flags (valid and scanned) (alle Flags zurücksetzen) resetFlags();
// mark root object as valid (Root-Objekt als valid markieren) setValid(rootObjectIndex);
// scan all objects forward (alle Objekte vorwärts scannen) for (i=l; i <= numberOfObjects; i++) { // is valid flag of object i set and scanned flag not yet set? // (ist valid-Flag des Objekts i gesetzt und das scanned Flag noch nicht?) if ( isValid(i) && üsScanned(i) ) { // mark all referenced objects of i as valid // (alle durch Objekt i referenzierten Objekte als valid markieren) for (j=0; j < objectList[i].numberOfReferences(); j++) { // mark referenced object j as valid // (referenziertes Objekt j als valid markieren) setValid(objectList[i].getReferenceIndex(j)); } // all references of object i are scanned => set scanned flag of object i // (alle Referenzen von Objekt i sind angescannt worden => // => scanned Flag des Objekts i setzen) setScanned(i);
}
// scan all objects backward (alle Objekte rückwärts scannen) for (i=numberOfObjects; i > 0; i~)
{ // is valid flag of object i set and scanned flag not yet set? // (ist valid-Flag des Objekts i gesetzt und das scanned Flag noch nicht?) if ( isValid(i) && üsScanned(i) ) { // mark all referenced objects of object i as valid // (alle durch Objekt i referenzierten Objekte als valid markieren) for (j=0; j < objectList[i].numberOfReferences(); j++) { // mark referenced object j as valid // (referenziertes Objekt j als valid markieren) setValid(objectList[i].getReferenceIndex(j)); } // all references of object i are scanned => set scanned flag of object i // (alle Referenzen von Objekt i sind angescannt worden // => scanned Flag des Objekts i setzen) setScanned(i); }
} (Algorithmus 2)
Algorithmus 2 umfasst einen Vorwärts-Durchlauf (Vorwärts-Scan) durch den Heap- Speicher, der im Wesentlichen dem von Algorithmus 1 entspricht, und einen Rück- wärts-Durchlauf (Rückwärts-Scan). Beim Rückwärts-Durchlauf von Algorithmus 2 sind insbesondere für die Objekte 6 und 8 die scanned-Flags gesetzt worden, die nach dem Vorwärts-Durchlauf noch nicht gesetzt waren. Für Objekt 7 ist beim Rückwärts-Durchlauf das valid-Flag gesetzt worden. Die während des Rückwärts- Durchlaufs zusätzlich zum Vorwärts-Durchlauf gesetzten Flags sind auch aus Fig. 6 ersichtlich, in der das Markierungsfeld aus Fig. 4 gezeigt ist, nachdem zusätzlich ein Rückwärts-Durchlauf auf den Heap-Speicher angewendet worden ist.
Bei einem nachfolgend angegebenen bevorzugten Algorithmus 3 wird zusätzlich ein binäres drittes Datenfeld „End-Flag" verwendet, das geschaltet wird, sobald ein
Durchlauf des Durchsuchens des Heap-Speichers vorgenommen worden ist, bei dem keine Markierung vorgenommen worden ist. Nach Durchlauf des Algorithmus 3 hat die Objektliste die in Fig. 8 dargestellte Gestalt und die Heap-Struktur die in Fig. 7 dargestellte Gestalt.
markValidObjekts (int rootObjectlndex, int numberOfObjects)
{ // reset all flags (valid and scanned) (alle Flags zurücksetzen) resetFlags();
// define endFlag (Definiton des binären End-Flags) boolean endFlag;
// mark root object as valid (Root-Objekt als valid markieren) setValid(rootObjectΙndex); do { // assume that this is the last scan (Annahme, dies sei der letzte Durchlauf) endFlag = true;
// scan all objects forward (alle Objekte vorwärts scannen ) for (i=l ; i <= numberOfObjects; i++)
{ // is valid flag of object i set and scanned flag not yet set? // (ist valid-Flag des Objekts i gesetzt und das scanned Flag noch nicht?) if ( isValid(i) && üsScanned(i) ) { // mark all referenced objects of i as valid // (alle durch Objekt i referenzierten Objekte als valid markieren) for (j=0; j < objectList[i].numberOfReferences(); j++) { // mark referenced object j as valid // (referenziertes Objekt j als valid markieren) setValid(objectList[i].getReferenceIndex(j));
// we have to do another run (scan) // (ein weiterer Durchlauf ist erforderlich, da eine // Markierung vorgenommen worden ist) endFlag = false; } // all references of object i are scanned // => set scanned flag of object i // (alle Referenzen von Objekt i sind abgescannt worden // => scanned Flag des Objekts i setzen) setScanned(i); } } if (endFlag = true)
{ // this was the last scan (das war der letzte Durchlauf) break; }
// assume that this is the last scan (Annahme, dies sei der letzte Durchlauf) endFlag = true;
// scan all objects backward (alle Objekte rückwärts scannen) for (i=numberOfObjects; i > 0; i— ) { // is valid flag of object i set and scanned flag not yet set? // (ist valid-Flag des Objekts i gesetzt und das scanned Flag noch nicht?) if ( isValid(i) && ÜsScanned(i) ) { // mark all referenced objects of object i as valid // (alle durch Objekt i referenzierten Objekte als valid markieren) for (j=0; j < objectList[i].numberOfReferences(); j++) { // mark referenced object j as valid // (referenziertes Objekt j als valid markieren) setValid(objectList[i].getReferenceIndex(j));
// we have to do another run (scan) // (ein weiterer Durchlauf ist erforderlich, da eine // Markierung vorgenommen worden ist) endFlag = false; } // all references of object i are scanned // => set scanned flag of object i // (alle Referenzen von Objekt i sind abgescannt worden => // => scanned Flag des Objekts i setzen) setScanned(i); } } } while (endFlag = false)
(Algorithmus 3) Der vorstehende Algorithmus 3 durchsucht den Heap-Speicher so oft abwechselnd vorwärts und rückwärts, bis ein Durchlauf (Scan) des Durchsuchens des Heap- Speichers vorgenommen worden ist, bei dem keine Markierung vorgenommen worden ist. Dies wird durch die (do, while)-Schleife verwirklicht, die als Bedingung für das Weitermachen hat, dass das End-Flag auf den booleschen Wert „false" geschaltet ist. Erst wenn in einem Durchlauf keine Markierung (valid-Flag) vorgenommen worden ist, bleibt das End-Flag auf den booleschen Wert „true" gesetzt und die (do, while)- Schleife und damit der Algorithmus wird beendet.
Fig. 7 zeigt die Heap-Struktur aus Fig. 1 und Fig. 3, nachdem Algorithmus 3 auf den zu Grunde liegenden Heap-Speicher angewendet worden ist, und Fig. 8 zeigt die zugehörige Objektliste. Alle Objekte der Heap-Struktur sind bereits als valid markiert. Der Zustand gemäß Fig. 7 und Fig. 8 ist auch der Zustand bei Beginn des letzten Durchlaufs der (do,while)-Schleife des Algorithmus 3. Da bei diesem Durchlauf keine Markierung an einem valid-Flag vorgenommen werden, bleibt das End-Flag auf „true" gesetzt, so dass die (do,while)-Schleife nach diesem letzten Durchlauf beendet wird.
Mit dem Verfahren, das durch den Algorithmus 3 implementiert ist, lassen sich somit für einen Heap-Speicher, dessen Heap-Struktur Rückwärtsreferenzen hat, sämtliche (noch) referenzierten Objekte finden. Gemäß Fig. 7 und 8 sind nur die nicht referenzierten Objekte 31, 32, 33, 29, 30, 23, 24 mit nicht markiertem valid-Flag übrig geblieben. Alle referenzierten Objekte sind markiert.

Claims

P a t e n t a n s p r u c h e
1. Verfahren zum Durchsuchen von dynamisch zugewiesenem Heap-Speicher nach referenzierten oder nicht referenzierten Objekten, bei dem ein Durchsuchen des Heap-Speichers mittels eines Algorithmus durchgeführt wird, der ohne Rekursion arbeitet.
2. Verfahren nach Anspruch 1, wobei jedem Objekt ein eindeutiger Objektindex zugewiesen ist, wobei durch die Objektindizes aller Objekte des Heap-Speichers eine eindeutige Reihenfolge der Objekte festgelegt ist, und wobei gemäß dem Algorithmus die Objekte des Heap-Speichers in der Reihenfolge ihrer Objektindizes abgesucht werden.
3. Verfahren nach Anspruch 1 oder 2, wobei die Objekte in dem Heap-Speicher nummeriert sind, und wobei gemäß dem Algorithmus die Objekte des Heap- Speichers in der Reihenfolge ihrer Nummerierung abgesucht werden.
4. Verfahren nach Anspruch 2 oder 3, wobei der Heap-Speicher bezüglich der Objektindizes bzw. Nummerierung vorwärtsgerichtet ist, und wobei der Heap-Speicher gemäß dem Algorithmus genau ein Mal durchsucht wird.
5. Verfahren nach Anspruch 2 oder 3, wobei der Heap-Speicher bezüglich der Objektindizes bzw. Nummerierung vorwärtsgerichtet ist, und wobei der Heap-Speicher gemäß dem Algorithmus genau zwei Mal durchsucht wird, wobei das zweite Mal des Durchsuchens zur Überprüfung durchgeführt wird, dass der Algorithmus beendet werden kann.
6. Verfahren nach Anspruch 2 oder 3, wobei der Heap-Speicher bezüglich der Objektindizes bzw. Nummerierung seiner Objekte mindestens ein Paar von referenzie- rendem Objekt ((i)) und referenzierten Objekt ((i+1)) aufweist, die zueinander eine Rückwärtsreferenz haben, und wobei der Heap-Speicher mindestens zwei Mal durchsucht wird.
7. Verfahren nach Anspruch 2 oder 3, wobei der Heap-Speicher bezüglich der Objektindizes bzw. Nummerierung seiner Objekte mindestens ein Paar von referenzierendem Objekt ((i)) und referenzierten Objekt ((i+1)) aufweist, die zueinander eine Rückwärtsreferenz haben, und wobei der Heap-Speicher mindestens drei Mal durch- sucht wird, wobei das letzte, insbesondere dritte, Mal des Durchsuchens zur Überprüfung durchgeführt wird, dass der Algorithmus beendet werden kann.
8. Verfahren nach einem der Ansprüche 2 bis 7, wobei der Heap-Speicher beginnend mit einem Start-Objekt (1), das einen niedrigsten Objektindex (1) hat, bis zu einem End-Objekt (40), das einen höchsten Obkjektindex (40) hat, durchsucht wird.
9. Verfahren nach einem der Ansprüche 2 bis 8, wobei der Heap-Speicher beginnend mit einem End-Objekt (40), das einen höchsten Objektindex (40) hat, bis zu einem Start-Objekt (1), das einen niedrigsten Objektindex (1) hat, durchsucht wird.
10. Verfahren nach den Ansprüchen 8 und 9 in Verbindung miteinander, wobei der Heap-Speicher mindestens je ein Mal vom Start-Objekt (1) zum End-Objekt (40) und, in umgekehrter Reihenfolge, vom End-Objekt (40) zum Start-Objekt (1) durchsucht wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, wobei jedes mittels des Algorithmus gefundene referenzierte aktuelle Objekte markiert wird.
12. Verfahren nach Anspruch 11, wobei das Verfahren beendet wird, sobald ein Durchlauf des Durchsuchens des gesamten Heap-Speichers durchgeführt worden ist, bei dem keine Markierung vorgenommen worden ist.
13. Verfahren nach Anspruch 11 oder 12, wobei das Markieren unter Verwendung eines für den Algorithmus zugänglichen Markierungsfeldes durchgeführt wird.
14. Verfahren nach Anspruch 13, wobei das Markierungsfeld in einem flüchtigen Speicher vorgesehen ist, insbesondere in einem RAM-Speicher.
15. Verfahren nach Anspruch 13 oder 14, wobei zum Markieren ein Markierungsfeld verwendet wird, das für das aktuelle Objekt ein erstes Datenfeld (valid-Flag) und ein zweites Datenfeld (scanned-Flag) aufweist, und wobei das erste Datenfeld (valid- Flag) markiert wird, falls das aktuelle Objekt referenziert ist, und wobei das zweite Datenfeld (scanned-Flag) markiert wird, falls alle von dem aktuellen Objekt ausgehenden referenzierten Objekte dadurch als referenziert markiert sind, dass bei diesen referenzierten Objekten das erste Datenfeld (valid-Flag) markiert ist.
16. Verfahren nach Anspruch 15, wobei das Verfahren beendet wird, sobald ein Durchlauf des Durchsuchens des gesamten Heap-Speichers durchgeführt worden ist, bei dem keine Markierung eines ersten Datenfeldes (valid-Flag) vorgenommen wor- den ist.
17. Verfahren nach einem der Ansprüche 1 bis 16, wobei mittels des Algorithmus gefundene Objekte, auf die keine oder noch keine Referenz gefunden wurde, nicht markiert und/oder übergangen werden.
18. Verfahren nach einem der Ansprüche 1 bis 17, wobei der Heap-Speicher in einem nichtflüchtigen Speicher, insbesondere EEPROM-Speicher, vorgesehen ist.
19. Datenträger, insbesondere Chipkarte, insbesondere Java Card, oder Chipmodul oder Chip zum Einbau in einen Datenträger, mit einem Mikroprozessor, mindestens einem Speicher und einem in dem Datenträger implementierten Verfahren nach einem der Ansprüche 1 bis 18.
PCT/EP2005/002552 2004-03-17 2005-03-10 Speicherbereinigung (garbage collection) für smart cards WO2005093580A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05715929A EP1728162A1 (de) 2004-03-17 2005-03-10 Speicherbereinigung (garbage collection) für smart cards

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004013180.5 2004-03-17
DE200410013180 DE102004013180A1 (de) 2004-03-17 2004-03-17 Speicherbereinigung (Garbage Collection) für Smart Cards

Publications (1)

Publication Number Publication Date
WO2005093580A1 true WO2005093580A1 (de) 2005-10-06

Family

ID=34961409

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/002552 WO2005093580A1 (de) 2004-03-17 2005-03-10 Speicherbereinigung (garbage collection) für smart cards

Country Status (3)

Country Link
EP (1) EP1728162A1 (de)
DE (1) DE102004013180A1 (de)
WO (1) WO2005093580A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8347055B2 (en) 2009-06-30 2013-01-01 Incard S.A. Method to defrag a memory of an IC card

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105279097B (zh) * 2014-07-07 2019-06-18 北京数码视讯科技股份有限公司 一种调用瞬态对象的管理方法、设备及智能卡

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6502110B1 (en) * 1999-03-31 2002-12-31 Koninklijke Philips Electronics N.V. Memory reclamation method and apparatus

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0433489A1 (de) * 1989-12-22 1991-06-26 Siemens Aktiengesellschaft Verfahren zur Bereinigung eines Speichers von Objekten, auf die während eines Programmlaufs nicht mehr zugegriffen werden kann
SE9002558D0 (sv) * 1990-08-02 1990-08-02 Carlstedt Elektronik Ab Processor
DE69332696T2 (de) * 1992-06-15 2003-08-21 Microsoft Corp Rechnerverfahren und System zur Speicherverwaltung
DE19918610A1 (de) * 1998-04-25 2000-10-26 Wolfgang Hilberg Korrelationsverfahren minimalen Aufwands mit der Methode des Stapelns
PT1157331E (pt) * 1999-02-25 2002-12-31 Siemens Energy & Automat Metodo "moniker" dispositivo e artigo de fabrico fundamento da invencao

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6502110B1 (en) * 1999-03-31 2002-12-31 Koninklijke Philips Electronics N.V. Memory reclamation method and apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BAKER H G JR ET AL: "The incremental garbage collection of processes", SIGPLAN NOTICES USA, vol. 12, no. 8, August 1977 (1977-08-01), pages 55 - 59, XP002333073, ISSN: 0362-1340, Retrieved from the Internet <URL:http://portal.acm.org/citation.cfm?id=872734.806932&coll=GUIDE&dl=GUIDE&CFID=48081954&CFTOKEN=73486992> [retrieved on 20050620] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8347055B2 (en) 2009-06-30 2013-01-01 Incard S.A. Method to defrag a memory of an IC card

Also Published As

Publication number Publication date
DE102004013180A1 (de) 2005-10-06
EP1728162A1 (de) 2006-12-06

Similar Documents

Publication Publication Date Title
DE69923657T2 (de) Markierung von gespeicherten datenobjekten für garbage-kollektoren
DE69836796T2 (de) Datenverarbeiter mit lokalisierter gedächtnisreklamierung
DE60032685T2 (de) Speicherrückforderungsverfahren
DE69932874T2 (de) Verfahren und Computersystem zur dynamischen Generationsverwaltung von Rechnerspeicher
DE69636761T2 (de) Speichern und wiederauffinden von geordneten schlüsselmengen in einem kompakten 0-kompletten baum
DE19743267C1 (de) Verfahren zum Aufsuchen einer Adresse in einem teilbesetzten, nicht balancierten Binären Baum
DE3416939A1 (de) Verfahren zur steuerung von betriebseinrichtungen
DE19959758A1 (de) Bestimmung der Art und der Genauigkeit von lokalen Variablen bei vorhandenen Subroutinen
DE2339741A1 (de) Anordnung zur bildung einer relativen adresse fuer einen speicher
WO1999017226A1 (de) Verfahren zum hinzufügen bzw. entfernen einer adresse in einem teilbesetzten, nicht-balancierten binären baum
DE1499182B2 (de) Datenspeichersystem
WO2000070620A1 (de) Speicheranordnung mit adressverwürfelung
DE102009059939A1 (de) Verfahren zum Komprimieren von Bezeichnern
DE2218839A1 (de) Verfahren und einrichtung zur zuteilung von speicheradressen zu datenelementen
DE60318993T2 (de) Eingebettete Speicherbereinigung
WO2005093580A1 (de) Speicherbereinigung (garbage collection) für smart cards
DE19538448B4 (de) Datenbankmanagementsystem sowie Datenübertragungsverfahren
DE2062164A1 (de) Verfahren zur Erzeugung eines mehr stufigen Index für gespeicherte Daten einheiten
EP1623394A1 (de) Speicherverwaltung bei einem tragbaren datentrager
DE112021004729T5 (de) Dreifarben-bitmap-array zur garbage-collection
DE69637329T2 (de) Speichermanagementsystem und verfahren
DE102004005290B3 (de) Verfahren und Vorrichtung zur Absicherung von Daten in einem nichtflüchtigen Datenspeicher
EP2284710A1 (de) Verfahren zum Verwalten von Speicherressourcen in einem portablen Datenträger
EP1530131B1 (de) Beschleunigtes Referenzfinden für eine automatische Speicherbereinigung (Garbage Collection)
DE3009330C2 (de) Verfahren zum Sortieren von in einem Hybrid-Assoziativspeicher gespeicherten Daten und Anordnung zur Durchführung des Verfahrens

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005715929

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005715929

Country of ref document: EP