WO2005093580A1 - Recuperation de l'espace memoire pour des cartes a puce - Google Patents

Recuperation de l'espace memoire pour des cartes a puce 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
German (de)
English (en)
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/fr
Publication of WO2005093580A1 publication Critical patent/WO2005093580A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/17Embedded application
    • G06F2212/177Smart card
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing 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/2143Clearing 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

L'invention concerne un procédé de balayage d'une mémoire en tas affectée de manière dynamique, au sujet d'objets référencés ou non référencés, au cours duquel le balayage de la mémoire en tas est effectué au moyen d'un algorithme fonctionnant sans récursion. Le procédé selon l'invention peut notamment être employé lors de la récupération automatique de l'espace mémoire. Pour ledit algorithme sans récursion, l'espace mémoire nécessaire à la mise en oeuvre de l'algorithme peut-être déterminé avant exécution. Par conséquent, le procédé selon l'invention est particulièrement destiné à des systèmes informatiques possédant des ressources mémoire limitées telles que par exemple des cartes à puce. L'invention concerne également un support mémoire correspondant, notamment une carte à puce, par exemple une carte Java dans laquelle le procédé selon l'invention est implémenté.
PCT/EP2005/002552 2004-03-17 2005-03-10 Recuperation de l'espace memoire pour des cartes a puce WO2005093580A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05715929A EP1728162A1 (fr) 2004-03-17 2005-03-10 Recuperation de l'espace memoire pour des cartes a puce

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=34961409

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/002552 WO2005093580A1 (fr) 2004-03-17 2005-03-10 Recuperation de l'espace memoire pour des cartes a puce

Country Status (3)

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

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 (fr) * 1989-12-22 1991-06-26 Siemens Aktiengesellschaft Méthode pour épurer une mémoire d'objets auxquels on n'a plus accès en cours d'exécution du programme
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
DE60000301T2 (de) * 1999-02-25 2003-01-30 Siemens Energy & Automat Verfahren, gerät, und hergestellter gegenstand für beinamen

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
EP1728162A1 (fr) 2006-12-06
DE102004013180A1 (de) 2005-10-06

Similar Documents

Publication Publication Date Title
DE69836796T2 (de) Datenverarbeiter mit lokalisierter gedächtnisreklamierung
DE60032685T2 (de) Speicherrückforderungsverfahren
DE60032694T2 (de) Speicherrückforderungsverfahren
DE69932874T2 (de) Verfahren und Computersystem zur dynamischen Generationsverwaltung von Rechnerspeicher
DE68926775T2 (de) System und Verfahren für eine allgemeine Schnittstelle für Anwendungsprogramme
DE3784387T2 (de) Vorrichtung und verfahren zur parallelen verwaltung von freien speicherbereichen.
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
DE3485999T2 (de) Hochgeschwindigkeitverarbeitungssystem fuer rechneranlage.
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
WO2000070620A1 (fr) Ensemble memoire avec hachage des adresses
DE102009059939A1 (de) Verfahren zum Komprimieren von Bezeichnern
DE2218839A1 (de) Verfahren und einrichtung zur zuteilung von speicheradressen zu datenelementen
DE60318993T2 (de) Eingebettete Speicherbereinigung
EP1728162A1 (fr) Recuperation de l&#39;espace memoire pour des cartes a puce
DE19538448B4 (de) Datenbankmanagementsystem sowie Datenübertragungsverfahren
DE10120615B4 (de) Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe
DE2062164A1 (de) Verfahren zur Erzeugung eines mehr stufigen Index für gespeicherte Daten einheiten
EP1623394A1 (fr) Gestion de memoire pour un support de donnees portatif
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 (fr) Procédé de gestion de ressources de stockage dans un support de données portable

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