DE102004022907A1 - Storage management media - Google Patents

Abstract

The invention provides an object oriented programming language data carrier having a microprocessor, non-volatile application memory (EEPROM) for program code containing packets and data containing objects in the object oriented programming language, and memory management for managing the nonvolatile application memory (EEPROM). The packages are designed as objects such that they appear as objects to memory management.

Description

The Invention relates to a an object-oriented programming language set up disk, in particular a chip, a chip module or a chip card with such Chip or chip module, with a microprocessor, with a non-volatile Application memory (EEPROM) for Program containing packets and data containing objects, and with a memory management to manage the non-volatile Application memory (EEPROM).

In particular, the invention relates to such a data carrier in a design of a Java Card, which is adapted to execute programs in the object-oriented programming language Java ^™ (Sun Microsystems), in particular by a virtual Java Card machine implemented in the data carrier.

Of the disk can a body in any external shape have, e.g. in standardized (e.g., ISO) or non-standardized Check card form, in the form of a voluminous token or in the form of a Chip module.

One disk typically has a microprocessor, multiple memory and optional one or more interfaces for contactless and / or contact-based Communication between the disk and external devices. As memory has the disk a non-volatile one System memory (ROM and / or flash memory if necessary), a non-volatile Application memory (EEPROM and / or possibly further flash memory) and a fleeting one Random Access Memory (RAM).

in the Following, according to the am common used embodiment a volume such as. a Java Card, the nonvolatile system memory as ROM referred to, the nonvolatile application memory as EEPROM and the volatile memory as RAM, even if the memory (especially ROM, EEPROM) quite or partially realized in other technologies (e.g., Flash) could be.

at a conventional one for one object oriented programming language established media (e.g. Java Card) is program code, e.g. for system functions or for applications, in the form of packages (packages) loaded into the disk. In addition to Program code, each package can contain other components such as e.g. an export component that allows access from outside of the package to the package. The packets become static, i. before the running time (before expiration) of the respective program in the disk loaded and there in one for that stored memory (e.g., ROM, EEPROM).

to Runtime of the program will be dynamic out of the associated package Created objects in which data is contained.

in the ROM of the conventional for one object oriented programming language set up disk especially the operating system stored, and possibly packages (packages) with system functions, or so-called preloaded packages, i. Packages that are loaded into the disk prior to completion of the disk become.

Of the EEPROM of the conventional for an object-oriented Programming medium set up contains, among other things, a substantially for program code provided package memory in the packages with program code and optionally other components (e.g., export component) are.

Further contains the conventional one EEPROM for Data is a heap memory in which at runtime of each called program dynamically created objects in which Data is included. By the dynamic creation of a respective The object in heap memory becomes the heap memory for the object required space allocated dynamically (allocated).

Optional system variables are also created in the EEPROM.

By splitting the EEPROM into a heap for objects, i.e. Data, and a package store for program code is memory management inflexible.

Especially This can be achieved by having two rigidly separated memory areas are, the available space in the EEPROM not optimally utilized and the probability that the memory will fragment is high.

Optional it is with a conventional EEPROM provided that the memory limit between the packet memory for program code and the heap memory for Objects, i. Data, if necessary by means of a designated Memory management is relocatable to the space in the EEPROM preferably exploit efficiently.

One Another disadvantage of the two-part EEPROM is that it is heterogeneous because the packet store and the heap store are different Requirements for memory management, causing memory management of the conventional two-parted one EEPROM awkward is.

More accurate has the heap memory on which the objects are dynamically created, often (at Java Cards e.g. in versions 2.2 and 3.0) via automatic garbage collection (Garbage collection), which releases unwanted heap memory. Some procedures or automatic garbage collection devices, e.g. Copy Collector or Compacting Collector, defragment the heap memory additionally.

Of the Package memory, in which packets are stored statically, requires one second implementation of automatic garbage collection, to use the memory optimally.

task The invention is a, for an object-oriented programming language set up with disk a microprocessor and a nonvolatile application memory (e.g., EEPROM) for Packages and objects and with a simple, efficient memory management for the To create application memory.

The Task is by a disk after the independent one Claim 1 solved. Advantageous embodiments of the invention are specified in the dependent claims.

Of the Inventive disk according to the independent claim 1 is for an object-oriented programming language is set up, so for example a Java Card with a Java Card Virtual Machine. The disk is equipped with a microprocessor, a non-volatile Application memory (e.g., EEPROM, Flash) for packets and objects in the object-oriented programming language and memory management to manage the non-volatile Application memory. The packages contain executable program code. The objects are at runtime of the program, which is the program code in the package corresponds dynamically. In the objects are essentially contain data at runtime of each Program, i. as soon as a program is called, be generated.

According to the invention Packages are also created as objects, allowing packages and objects in the same unified memory area of the application memory can be created. To manage the objects that now contain program code or data can, Therefore, only a single unified storage management is required, namely one Memory management that can manage objects. In other words exist for memory management in application memory only objects that are in one for Objects usual Way managed by the memory management. This is by the invention, the administrative burden of memory management reduced, and memory management can work more efficiently.

Therefore is according to claim 1 one for an object-oriented programming language set up disk with a microprocessor and a nonvolatile application memory for packages and created objects that are particularly simple and efficient Memory management for the non-volatile Application memory has.

moreover needed none of the application memory managed by memory management Memory limit that would need to be managed. Because the packages as Objects are created, is a subdivision of the application memory in an area for Packages (essentially program code and possibly other components like expon components) on the one hand and objects (essentially data) on the other required. Preferably, the one managed by the memory controller Application memory also a uniform memory area without memory limit (i.e., without an internal memory limit within memory management managed application memory). The omission of the memory limit on the one hand results in a reduced administrative burden. On the other leaves to complete the application memory more efficiently, so that the memory resources the application memory are used efficiently and the risk of a Fragmentation is less.

Preferably is the application memory managed by space management a - in particular allocating dynamically - heap memory.

According to one preferred variant, the package is more accurate than one or more Objects created by field type (Array Type Object). Such an object The field type is a data field (array) with a plurality of field elements (Array Elements): In the field elements is the contents of the package stored. In particular, with a Java Card according to this variant, that is Package preferably in the form of a Java byte array created, that is in shape a data field (array) with a plurality of individual field elements, each one byte (8 bits) long (large), or in the form of several such Java byte arrays.

According to a preferred development of the invention, the data carrier also has a device for automatic garbage collection, which is set up for the automatic garbage collection of the application memory managed by the storage management. Examples of automatic garbage collections used are Mark and Sweep Garbage Collection and variations thereof. The automatic garbage collection eliminates in the before zugten development of the invention, if necessary, not only no longer needed data (conventional objects), but also no longer required program code and possibly export components or other package components that are designed to the outside also as objects. No special garbage collection is required to remove unneeded packages. For this reason, memory management according to the preferred embodiment is particularly efficient, especially in automatic garbage collection.

Further can the disk have a defragmentation facility for defragmentation of the application storage managed by the storage manager is.

Optional is the possibly provided automatic garbage collection (garbage Collection) additionally set up to defragment the memory area. For example is called automatic garbage collection with built-in defragmentation a copy collector or a compacting collector or a modification one of the two automatic garbage collections used.

Preferably is a stored in the application memory package as used marked so that the package is not deleted by garbage collection. The marking of the package is made in a manner usual for objects, according to the feature that the package as one or more objects is created. For example, the marker is in the object header contain. The tag can optionally be in a registry of the application memory be included, which is a listing of all in application memory contains contained packages. More preferably, as soon as a packet is deleted, the mark of the Package as used again reversed.

in the The following is the invention with reference to embodiments and below Reference to the drawing closer explains in the show:

1 a schematic representation of an application memory EEPROM with a heap memory arranged therein 101 according to an embodiment of the invention;

2 a schematic representation of an application memory EEPROM according to the prior art, with a heap memory 201 and a package store 202 caused by a movable storage limit 203 are separated from each other;

1 shows a schematic representation of an application memory EEPROM according to an embodiment of the invention. The EEPROM contains a registry 110 , a memory manager 120 (Memory Management) and a heap memory 101 , The heap memory 101 is designed uniformly and accommodates both conventional objects, ie data, as well as according to the invention designed as objects packages, ie program code (and possibly export components, etc.). In the heap store 101 are more precisely three dynamically created conventional data objects 102 . 103 . 104 and a packet designed according to the invention as a byte array object 105 arranged. Both the data objects 102 . 103 . 104 as well as the package object 105 are for memory management 120 that the heap memory 101 managed, objects.

For comparison shows 2 a schematic representation of an application memory EEPROM according to the prior art, with a heap memory 201 and a package store 202 caused by a movable storage limit 203 are separated from each other. The conventional heap memory 201 is reserved for the data and contains only dynamically created conventional objects, here the two objects 204 and 205 , Packages - and thus in particular program code - are, however, in a separate packet memory 202 saved, here is a single package 206 in the package store 202 stored. The heap memory 201 has its own memory management 211 , and the package store 202 also has its own memory management 212 , The memory limit 203 that the heap memory 201 and the package memory 202 separated from each other is movable, so that the memory allocation can be adjusted if necessary to the memory needs of a running program. The EEPROM also contains a registry 210 (see below).

In the 1 shown type of memory allocation, which knows only objects is much more flexible than the conventional type of memory allocation according to 2 , which has to differentiate between objects and packages, as in memory allocation according to 1 to manage a unified storage area without storage limits, in which all storage elements 102 . 103 . 104 . 105 look "outward" for memory management the same as objects, hence the unified application memory 101 that knows only objects, with a single unified memory management 120 out.

For a Java Card, an overview of all the packages contained in the EEPROM is contained in the registry of the EEPROM. For a single package, the registry contains either a single entry or - more commonly - several so-called package data entries (Package Data Entries), which correspond to the program code and possibly existing other components such as the export component chen. Despite its name "package data entry", the entry in the registry does not represent data, but program code. For the program code of a single package, the registry usually contains a single package data entry, alternatively several package data entries. For any additional components in the package, such as export components, the registry contains one or more additional package data entries. For objects with data, the registry of the Java Card may have one or more instance entries. Packet data entries for implemented packages are marked as used in the registry. When a package is deleted, the tag of the package is deleted. According to the invention, where an object is applied to each packet data entry, the flag may be included as used, for example, in the object header of the object corresponding to the packet data object.

Should now a package can be implemented in the EEPROM of a Java Card, First, the registry of the EEPROM is created or added to the package. According to the invention will follow for each Package data entry that is included with the package in the registry, An object is created in the heap memory of the Java Card. This is the program code is implemented in the EEPROM. Nevertheless, the EEPROM contains only objects that are consistent through memory management can be treated. Unless the heap memory over Garbage Collection (automatic garbage collection) can also the program code, which takes the form of one or more objects garbage collection, what with usual Procedure or data carriers not possible is.

Claims (10)

Data carrier, set up for an object-oriented programming language, comprising - a microprocessor, - a nonvolatile application memory (EEPROM, Flash) for program code-containing packets and data objects containing dynamic objects in the object-oriented programming language, and - memory management ( 120 ) for managing the non-volatile application memory (EEPROM, Flash) or at least a part thereof, the memory management ( 120 ) managed application memory at least one package ( 105 ) created as one or more objects such that the package ( 105 ) appears to memory management as one or more objects. A data carrier according to claim 1, wherein 120 ) managed application memory (EEPROM, Flash) is a uniform memory area without memory limit. A data carrier according to claim 1 or 2, wherein the storage management ( 120 ) managed application memory - especially heap memory to allocate dynamically ( 101 ). A data carrier according to any one of claims 1 to 3, wherein the packet ( 105 ) is created as one or more objects of the field type. disk according to one of the claims 1 to 4, wherein the for an object-oriented programming language set up a disk Java Card is. A data carrier according to any one of claims 1 to 5, further comprising means for automatic garbage collection for automatically garbage collection management ( 120 ) managed application memory is set up. A data carrier according to any one of claims 1 to 6, further comprising defragmentation means for defragmenting the storage device ( 120 ) managed application memory is set up. A data carrier according to any one of claims 1 to 7, wherein the package ( 150 ) is marked as used. A method of operating an object oriented programming language disk as claimed in any one of claims 1 to 7, wherein the disk comprises a microprocessor, nonvolatile application memory (EEPROM, Flash) for program code containing packets, and dynamic object objects in the object oriented programming language, and a memory management ( 120 ) for managing the nonvolatile application memory (EEPROM, Flash) or at least part of the application memory (EEPROM, Flash), wherein in the method in the memory management ( 120 ) managed application memory at least one package ( 105 ) is created as one or more objects such that the package ( 105 ) compared to memory management ( 120 ) as an object or multiple objects appears. The method of claim 9, wherein additionally an automatic garbage collection and / or defragmentation of the memory management ( 120 ) managed application memory (EEPROM, Flash).