EP1623394A1 - Speicherverwaltung bei einem tragbaren datentrager - Google Patents

Speicherverwaltung bei einem tragbaren datentrager

Info

Publication number
EP1623394A1
EP1623394A1 EP04730985A EP04730985A EP1623394A1 EP 1623394 A1 EP1623394 A1 EP 1623394A1 EP 04730985 A EP04730985 A EP 04730985A EP 04730985 A EP04730985 A EP 04730985A EP 1623394 A1 EP1623394 A1 EP 1623394A1
Authority
EP
European Patent Office
Prior art keywords
memory area
program
memory
data carrier
objects
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04730985A
Other languages
English (en)
French (fr)
Inventor
Thomas Stocker
Georg Kramposthuber
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and 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 and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP1623394A1 publication Critical patent/EP1623394A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis

Definitions

  • the invention relates generally to the technical field of memory management when executing a program using a portable data carrier that has a processor.
  • a portable data carrier can in particular be a chip card in different designs or a chip module.
  • the invention relates to the use of two different storage areas of the data carrier in order to store objects generated during the execution of the program.
  • RAM volatile read / write memory
  • EEPROM non-volatile writable memory
  • ROM mask-programmed read-only memory
  • a write to RAM takes considerably less time - e.g. 30 times less - than a write to the EEPROM.
  • a bit in RAM occupies significantly more space on a semiconductor chip of the data carrier than a bit in EEPROM, so that as a rule only relatively little RAM is provided. There is therefore the problem of using the fast but scarce RAM as well and flexibly as possible.
  • Portable data carriers with complex memory management functions are known, for example, under the Java Card TM brand.
  • Chapter 5 shows that persistent objects are typically stored in the EEPROM of the data carrier, while transient objects are typically be created in RAM. For security reasons, the storage of transient objects in the EEPROM is not permitted.
  • transient objects such as those e.g. on pages 81-85 of the document "Java Card TM 2.1 Application Programming Interface", June 2002, published by Sun Microsystems, Inc., Palo Alto, USA, available on the Internet at the above address.
  • transient objects as such have a potentially unlimited lifespan; the term “transient” only refers to the data stored in the objects. The use of transient objects therefore only slightly increases the flexibility in memory management.
  • the object of the invention is accordingly to at least partially avoid the problems of the prior art and to provide a memory management technology for a portable data carrier, by means of which the use of an efficiently writable memory area - typically a RAM memory - is improved.
  • the invention is intended to enable flexible use of the RAM memory without any effort for the programmer.
  • this object is achieved in whole or in part by a method according to claim 1 for memory management when executing a program, a method according to claim 7 for implementing a source program, a portable data carrier according to claim 12 and a computer program product according to claim 13.
  • a method according to claim 1 for memory management when executing a program a method according to claim 7 for implementing a source program, a portable data carrier according to claim 12 and a computer program product according to claim 13.
  • the invention is based on the basic idea of automatically storing certain objects, which are generated by the portable data carrier when the program is executed, in an efficiently writable memory area - e.g. in RAM - to create. Objects that only have a short lifespan are particularly suitable for this. Such objects are referred to in the present document as "local objects". Local objects in the sense of the invention can e.g. exception types as they are generated when exceptions occur. The lifetime of an exception object ends as soon as the corresponding exception has been caught.
  • the invention allows temporarily required storage space to be made available temporarily and dynamically - namely in the form of a local object.
  • the local object is partially or completely in RAM or another efficiently writable memory.
  • This memory is used particularly well by the automatic and dynamic memory management of the invention. This increases the performance of the data carrier both with regard to the processing speed and with regard to the storage space which is effectively available for the programs being executed.
  • a local object can be defined in particular by the fact that there is no persistent reference to the object.
  • a "persistent reference” is to be understood as a reference to the object that is persistent, e.g. is stored in a field of an object, a static field or a field of an array. As soon as a reference to an object is entered in one of the fields mentioned, the object can no longer be a local object.
  • Non-persistent references to an object e.g. are contained in the operand stack or in a local variable, however, do not affect the classification of an object as a local or non-local object.
  • the distinction as to whether an object is to be treated as a local or a non-local object can be made at the compile time of the program or at runtime or partly at compile time and partly at runtime. If there is a distinction at runtime, at least some newly created objects are initially created in the second, efficiently writable memory area. During the further execution of the program, it is monitored whether a persistent reference to the object is created. Once this is the case, the object can no longer be treated as a local object. It is then transferred to the first, non-volatile memory area. If a distinction is made at compile time, the compiler analyzes a section of the source program that contains the creation of the object to determine whether a persistent reference to the object is created.
  • the compiler then generates program code that creates the object in the first or - in whole or in part - in the second memory area.
  • the term "compiler” is intended to encompass all programs in the wording of the present document which carry out automatic conversion processes.
  • converters for generating CAP files (card application files) and optimization programs should also be referred to as "compilers”.
  • a source program analysis at compile time can usually only give an approximate result. This means that at least one of the two classifications of an object as local or non-local is subject to a certain degree of uncertainty. It can therefore be provided that only objects recognized as locally are created in the second memory area, while all other objects are created in the first memory area. In an alternative embodiment, on the other hand, only the objects that are reliably recognized as non-local are created in the first memory area, while all other objects are created in the second memory area. At least for objects that could not be classified as local, the run time monitoring described above is then carried out. In some embodiments, compiler directives (pragmas). provided with which objects can be identified as local or non-local.
  • simple criteria are used, optionally at runtime or at compile time, to determine whether objects should be created in the first or first in the second memory area. For example, it can be provided that objects generated by the program's znsr ⁇ H method are created in the first memory area. In different embodiments, either all other objects can first be created in the second memory area or only individual types of objects. Such object types can be, for example, exception objects or objects that are only needed temporarily for cryptographic operations.
  • the lifespan of a local object usually ends with the termination - either by a return or an exception - of the method in which the local object was created, because at this point the possibly existing local references the object will be deleted.
  • the storage space required for the object in the second storage area can then be released.
  • An exception to the rule just mentioned applies if the object is used as the return parameter of the method that created the object. In this case, the calling method receives a reference to the object, so that the object must not be deleted at least until this method is terminated.
  • a garbage collection is provided in some embodiments.
  • this causes time expenditure during program execution and increases the complexity of the runtime environment.
  • a particularly simple method is therefore preferably used, in which a fill level indicator indicates the occupancy of the second memory area.
  • the level pointer is usually reset to the level it was when it was called had this method.
  • An exception to this rule is made in preferred embodiments only if the portion of the second memory area released by the reset contains an object which is used as the return parameter of the method.
  • an object In order to ensure that an object can be transferred from the second to the first memory area when necessary, it is preferably checked when the object is created in the second memory area whether there is also sufficient space for the object in the first memory area. During the further execution of the program, when new objects are created, it is preferably ensured that there is always enough space in the first memory area for any necessary transfer of objects.
  • the first memory area is located in an EEPROM or some other non-volatile writable memory of the data carrier, while the second memory area is arranged in a RAM or other efficiently writable memory.
  • the second memory area can in particular be designed as a local heap and / or in a stack. Storage in a batch memory is particularly advantageous for objects that were already identified as local objects at compile time.
  • the computer program product according to the invention has program instructions in order to implement the implementation method according to the invention.
  • a computer program product can be a physical medium, for example a semiconductor memory or a floppy disk or a CD-ROM, on which a program for executing a method according to the invention is stored.
  • the computer program product can also be a non-physical medium, for example one via one Computer network transmitted signal.
  • the computer program product is preferably a compiler which is provided for execution by a conventional workstation computer in order to generate programs for portable data carriers.
  • the data carrier and / or the computer program product have features which correspond to the features described above and / or to the features mentioned in the dependent method claims.
  • FIG. 1 is a block diagram of a portable data carrier according to an embodiment of the invention.
  • FIG. 2 shows a flowchart of a method carried out when a new object is created
  • FIG. 3 shows an example of the memory allocation in a stack and a local heap during program execution
  • FIG. 5 is a schematic representation of the implementation of a Que ⁇ programm in an executable program.
  • the data carrier 10 shown in FIG. 1 is configured in the present exemplary embodiment as a chip card in accordance with the Java Card standard. On a single semiconductor chip, the data carrier 10 has a processor 12, a plurality of memory fields configured in different technologies and an interface circuit 14 for contactless or contact-based communication.
  • a read-only memory 16 a non-volatile writable memory 18 and a read / write memory 20 are provided as memory fields.
  • the read-only memory 16 is in the form of a ROM-programmed ROM, the non-volatile memory 18 in the form of an electrically erasable and programmable EEPROM and the read / write memory 20 in the form of RAM.
  • Write operations to the non-volatile memory 18 are relatively complex and, for example, take thirty times as long as write operations into the read / write memory 20.
  • system programs 22 are contained which are required for the operation of the data carrier 10.
  • the system programs 22 include an operating system 24 and program code 26 for implementing a virtual machine 26, which in the present exemplary embodiment is designed as a JCVM (J ⁇ v ⁇ Card Virtual Machine).
  • a class library 28 is also provided that provides application programming interfaces.
  • the program 30 has several methods 30.1, 30.2, 30.3, 30.4, which are referred to in the following as 30.x.
  • the methods 30.x comprise a method for installing the program 30, designated “install”, a method called “process” for processing incoming data packets and, if appropriate, methods “select” and “deselect” which are used when changing can be called between several programs of the data carrier 10.
  • a stack memory 32 located in the read / write memory 20 takes operands, return addresses, local ones during the program execution
  • the free area of the stack 32 is illustrated by hatching in FIG. 1.
  • a first memory area 34 is reserved in the non-volatile memory 18 and is designed in a manner known per se as a persistent heap (heap or heap). According to the usual Java card architecture, all objects, static data fields and non-transient arrays would be created in this persistent heap. In contrast, in the present exemplary embodiment the persistent heap is only used selectively. Local objects that are likely to have a short lifespan and to which no persistent references refer are not created in the first memory area 34, but in a second memory area 36 in the read / write memory 20. The second memory area 36 is also referred to as a local heap because, like the persistent heap, it serves to store objects.
  • FIG. 1 shows, by way of example, two objects 38, 0 created in the first memory area 34, each of which has a plurality of data fields.
  • One of the data fields of the first object 38 contains a reference 42 to the second object 40.
  • the reference 42 is also referred to as a "persistent reference” because it is contained in a persistently stored data field.
  • the second object 40 is not a local, but a persistent object, since the persistent reference 42 refers to it.
  • a local object 44 is shown as an example in the second memory area 36.
  • a local reference 46 which is contained, for example, in a local variable created in the stack 32, refers to the local object 44.
  • a further value in the stack 32 indicates as fill level pointer 48 the beginning of the free memory in the second memory area 36; this free memory is shown hatched in Fig. 1.
  • step 50 it is first checked whether there is enough storage space in the first memory area 34 to create the new object If there is not enough storage space available, the object generation is terminated with an error message
  • the check in step 50 in the present exemplary embodiment takes place regardless of the type of object to be created, in order to ensure that an object initially created in the second memory area 36 is also available at all times can be transferred into the first memory area 34.
  • step 52 it is therefore queried whether the program installation is taking place. If this is the case, the new object is generated in step 54 as a persistent object in the first memory area 34.
  • the generation process carried out in step 54 corresponds to the creation of an object in the persistent heap carried out with a conventional Java card. If it was determined in step 52 that the program execution is outside the installation method, the object to be newly created is initially regarded as a local object in the present exemplary embodiment. It is then created in the second memory area 36 - the local heap - if there is enough memory space available there. The latter is checked in step 56.
  • step 58 If there is enough storage space in the local heap, the object is created there in step 58 at the next free position - immediately afterwards in the area previously used - and the fill level pointer 48 is updated accordingly. If, on the other hand, the local heap is already too full, the usual object creation process takes place in step 54 in the first memory area 34, in which - as checked in step 50 - there is still sufficient free memory space available.
  • each time a persistent reference is generated or changed it is checked whether the reference refers to an object located in the second memory area 36. If this is the case, then the object is transferred to the first memory area 34 from the second 'storage area 36th The query in step 50 ensures that this is possible at any time.
  • the second memory area 36 is organized in a manner similar to a stack memory, in order to be able to release the memory space occupied by the local objects generated in this method 30.x in a simple manner after a method 30.x has ended.
  • FIG. 3 shows an example occupancy of the stack memory 32 with a plurality of stack frames (stach frames) 60.1, 60.2, 60.3.
  • stack frames stack frames
  • a new stack frame 60.x is created which is deleted again when method 30.x is ended becomes.
  • the stack frame 60.x contains a return address for the calling method, administration and backup data and, if applicable, local variables of the called method.
  • each stacking frame 60, x furthermore has a fill level field 62.x, which contains the fill level indicator 48 during the execution of the corresponding method 30.x. 3, the fill level field 62.3 contains the current fill level pointer 48, and the fill level field 62.2 contains the fill level that applied when the method corresponding to the stack frame 60.3 was called.
  • Section 64.3 denotes the section in the local heap that has been occupied by the currently executed method since it was called. Sections 64.1 and 64.2 in the local heap were filled by those methods that were called up to create memory frames 60.1 and 60.2, respectively.
  • the space occupied by this method in the second memory area 36 is generally completely released when a method is ended. This takes place without further action in that when a method is ended, the corresponding stack frame 60.x - including the fill level field 62.x contained therein - is discarded, and in that the fill level field 62. (xl) of the next older stack frame 62. (xl) also its assignment stored there is used as a new level indicator 48. For example, after the end of that method, when the stack frame 60.3 was called, the content of the fill level field 62.2 is used as the new fill level pointer 48, so that the entire memory section 64.3 is released.
  • step 70 either the fill level field 62. (xl) of the previous stack frame 60. (xl) is reactivated (step 72), or the value of the current fill level pointer 48 in the previous stack frame 60. (xl) accepted.
  • FIG. 5 shows the known translation process of a J u ⁇ source program 80 by a compiler 82 into a CAP file (Card Application File) 84.
  • the CAP file 84 is in turn loaded by a loading program 86 into the data carrier 10 as a program 30, for example when the data carrier 10 is initialized.
  • the compiler 82 also has, in addition to the actual compilation module for translating the source program 80 into bytecode, a converter which carries out various correctness checks and is also referred to as an "off-card virtual machine".
  • a simple query was carried out in step 52 to determine whether a new object to be created should be created in the first or in the second memory area 34, 36. Further runtime checks were carried out for the system and for updates of persistent references.
  • alternative embodiments provide for all or part of the aforementioned checks to be advanced to the level of the compiler 82.
  • the compiler 82 can obtain information as to whether an object to be newly created during the later program execution is to be regarded as a local or as a non-local object. Depending on the result of this analysis, the compiler 82 then generates program code which either creates the object in the first memory area 34 or in the second memory area 36. In alternative embodiments, objects that were reliably recognized as local at compile time, such as local variables, are created in the stack 32. Depending on whether a local heap is additionally provided in the read / write memory 20, the stack memory 32 forms the entire second memory area 36 or part of the second memory area 36 in these configurations.
  • the source program 80 will receive commands for creating objects which cannot be clearly classified as local or non-local objects at compile time.
  • objects can either be immediately created in the first memory area 34, or they can first be created as local objects in the second memory area 36 in the manner described above and can only be transferred to the first memory area 34 if necessary.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

Bei einem Verfahren zur Speicherverwaltung bei der Ausführung eines Programms (30) durch einen tragbaren Datenträger (10), der einen ersten und einen zweiten Speicherbereich (34, 36) zur Speicherung von bei der Programmausführung erzeugten Objekten (38, 40, 44) aufweist, wird ein Objekt (38, 40, 44) zunächst zumindest zum Teil im zweiten Speicherbereich (36) angelegt. Falls im Zuge der weiteren Programmausführung eine persistente Referenz (42) auf das Objekt (38, 40, 44) erzeugt wird, so wird es in den ersten Speicherbereich (34) übertragen. Bei einem Verfahren zum Umsetzen eines Quellprogramms (80) in ein ausführbares Programm (30) erfolgt zur Compilezeit eine Überprüfung, ob eine persistente Referenz (42) auf ein neu anzulegendes Objekt (38, 40, 44) erzeugt wird. In Abhängigkeit von dem Ergebnis dieser Überprüfung wird Programmcode erzeugt, der das Objekt (38 40 44) entweder im ersten oder zumindest zum Teil im zweiten Speicherbereich (34, 36) anlegt. Die Erfindung stellt eine Technik zur Speicherverwaltung bei einem tragbaren Datenträger (10) bereit, durch die die Nutzung eines effizient beschreibbaren Speicherbereichs verbessert wird.

Description

Speicherverwaltung bei einem tragbaren Datenträger
Die Erfindung betrifft allgemein das technische Gebiet der Speicherverwal- tung bei der Ausführung eines Programms durch einen tragbaren Datenträger, der einen Prozessor aufweist. Ein derartiger tragbarer Datenträger kann insbesondere eine Chipkarte in unterschiedlichen Bauformen oder ein Chipmodul sein. Spezieller betrifft die Erfindung die Nutzung zweier unterschiedlicher Speicherbereiche des Datenträgers, um während der Programm- ausführung erzeugte Objekte zu speichern.
Bei tragbaren Datenträgern sind generell mehrere Speicherbereiche vorgesehen, die in unterschiedlichen Speichertechnologien ausgeführt sind. Typischerweise ist der Speicher in einen flüchtigen Schreib-/ Lesespeicher (RAM), einen nicht-flüchtigen beschreibbaren Speicher (EEPROM) sowie einen rnaskenprogrammierten Festwertspeicher (ROM) unterteilt. Ein Schreibvorgang in das RAM benötigt erheblich weniger Zeit - z.B. um den Faktor 30 weniger - als ein Schreibvorgang in das EEPROM. Andererseits nimrat ein Bit im RAM deutlich mehr Fläche auf einem Halbleiterchip des Datenträgers ein als ein Bit im EEPROM, so daß in der Regel nur relativ wenig RAM vorgesehen ist. Es besteht daher das Problem, das schnelle, aber knappe RAM möglichst gut und flexibel zu nutzen.
Tragbare Datenträger mit komplexen Speicherverwaltungsfunktionen sind z.B. unter der Marke Java Card™ bekannt. Das Dokument "Java Card™ 1.1 Runtim Environment (JCRE) Specification" , Juni 2002, herausgegeben von der Firma Sun Microsystems, Inc., Palo Alto, USA, im Internet verfügbar unter http://java.sun.com/products/javacard, beschreibt die in einer Java Card bereitgestellte Umgebung zur Ausführung von Programmen (Java Card Applets). In Kapitel 5 ist dargestellt, daß persistente Objekte typischerweise im EEPROM des Datenträgers gespeichert werden, während transiente Objekte typischer- weise im RAM angelegt werden. Aus Sicherheitsgründen ist die Speicherung transienter Objekte im EEPROM nicht zulässig.
Bei der gerade beschriebenen Speicherverwaltung einer Java Card werden zur Erzeugung transienter Objekte spezielle Systemaufrufe verwendet, wie sie z.B. auf den Seiten 81 - 85 des Dokuments "Java Card™ 2.1 Application Programming Interface", Juni 2002, herausgegeben von der Firma Sun Microsystems, Inc., Palo Alto, USA, verfügbar im Internet unter der oben genannten Adresse, beschrieben sind. Dies schränkt den Umfang ein, in dem transiente Objekte in der Praxis benutzt werden. Überdies haben transiente Objekte als solche eine potenziell unbeschränkte Lebensdauer; die Bezeichnung "transient" bezieht sich lediglich auf die in den Objekten gespeicherten Daten. Die Nutzung transienter Objekte bewirkt daher nur eine geringe Steigerung der Flexibilität bei der Speicherverwaltung.
Die übliche und empfohlene Praxis bei der Programrnierung einer Java Card ist es, alle Objekte, die während der gesamten Lebensdauer eines Programms (Applet) benötigt werden, bei der Installation des Programms statisch anzulegen. Dies geschieht in einer Methode mit dem vorgegebenen Namen "install". Die genannte Praxis hat jedoch eine wenig flexible und damit nicht optimale Speicherverwaltung zur Folge. Wenn beispielsweise in einem Programm, ein transientes Feld angelegt wird, um temporäre Daten für kryptographische Operationen zu speichern, so ist der hierfür im RAM statisch reservierte Speicherplatz für andere Programme in der Regel verloren. Innerhalb des Programms hängt es von der Geschicklichkeit des Programmierers ab, inwieweit solcher reservierter Speicherplatz auch für andere Aufgaben herangezogen wird. Es wäre deshalb wünschenswert, die Nutzung des knappen Speicherplatzes im RAM zu verbessern und die Speicherverwaltung zu automatisieren. Die Erfindung hat demgemäß die Aufgabe, die Probleme des Standes der Technik zumindest zum Teil zu vermeiden und eine Technik zur Speicherverwaltung bei einem tragbaren Datenträger bereitzustellen, durch die die Nutzung eines effizient beschreibbaren Speicherbereichs - typischerweise eines RAM-Speichers - verbessert wird. Insbesondere soll durch die Erfindung eine flexible Nutzung des RAM-Speichers ohne Aufwand für den Pro- gramr ierer ermöglicht werden.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1 zur Speicherverwaltung bei der Ausführung eines Programms, ein Verfahren gemäß Anspruch 7 zum Umsetzen eines Quellprogramms, einen tragbaren Datenträger gemäß Anspruch 12 und ein Computerprogrammprodukt gemäß Anspruch 13. Die abhängigen Ansprü- ehe betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung beruht auf der Grundidee, bestimmte Objekte, die bei der Ausführung des Programms durch den tragbaren Datenträger erzeugt werden, automatisch in einem effizient beschreibbaren Speicherbereich - z.B. im RAM - anzulegen. Hierfür kommen insbesondere solche Objekte in Frage, die nur eine kurze Lebenszeit besitzen. Derartige Objekte werden im vorliegenden Dokument als "lokale Objekte" bezeichnet. Lokale Objekte im Sinne der Erfindung können z.B. exception-Otyekte sein, wie sie beim Auftreten von Ausnahmen (exceptions) erzeugt werden. Die Lebenszeit eines exception- Objekts endet, sobald die entsprechende Ausnahme gefangen worden ist.
Durch die Erfindung kann temporär benötigter Speicherplatz kurzzeitig und dynamisch - nämlich in Form eines lokalen Objekts - zur Verfügung gestellt werden. Das lokale Objekt wird zum Teil oder vollständig im RAM oder einem anderen effizient beschreibbaren Speicher angelegt. Durch die automatische und dynamische Speicherverwaltung der Erfindung wird dieser Speicher besonders gut genutzt. Dies erhöht die Leistungsfähigkeit des Datenträgers sowohl im Hinblick auf die Verarbeitungsgeschwindigkeit als auch im Hinblick auf den für die ausgeführten Programme effektiv zur Verfügung stehenden Speicherplatz.
Allgemein ist die Lebenszeit eines Objekts dann beendet, wenn keine Referenzen auf das Objekt mehr existieren, weil dann kein Zugriff auf das Objekt mehr möglich ist. Ein lokales Objekt kann insbesondere dadurch definiert sein, daß keine persistente Referenz auf das Objekt existiert. Als "persistente Referenz" soll hierbei eine Referenz auf das Objekt verstanden werden, die persistent, z.B. in einem Feld eines Objekts, einem statischen Feld oder einem Feld eines Array, gespeichert ist. Sobald eine Referenz auf ein Objekt in eines der genannten Felder eingeschrieben wird, kann das Objekt kein lokales Objekt mehr sein. Nicht-persistente Referenzen auf ein Objekt, die z.B. im Operandenstapel oder in einer lokalen Variablen enthalten sind, beeinflussen die Einordnung eines Objekts als lokales oder nicht-lokales Objekt dagegen nicht.
Die Unterscheidung, ob ein Objekt als lokales oder als nicht-lokales Objekt zu behandeln ist, kann zur Compilezeit des Programms oder zur Laufzeit oder teils zur Compilezeit und teils zur Laufzeit erfolgen. Bei einer Unterscheidung zur Laufzeit werden zumindest manche neu erzeugten Objekte zunächst im zweiten, effizient beschreibbaren Speicherbereich angelegt. Während der weiteren Prograrnmausführung wird überwacht, ob eine persistente Referenz auf das Objekt angelegt wird. Sobald dies der Fall ist, kann das Objekt nicht länger als lokales Objekt behandelt werden. Es wird dann in den ersten, nicht-flüchtigen Speicherbereich übertragen. Bei einer Unterscheidung zur Compilezeit analysiert der Compiler einen Abschnitt des Quellprogramms, der die Erzeugung des Objekts beinhaltet, daraufhin, ob eine persistente Referenz auf das Objekt angelegt wird. In Abhängigkeit vom Ergebnis der Analyse erzeugt der Compiler dann Programmcode, der das Objekt im ersten oder - ganz oder teilweise - im zweiten Speicherbereich anlegt. Der Begriff "Compiler" soll in der Wortwahl des vorliegenden Dokuments alle Programme umfassen, die automatische Umsetzvorgänge ausführen. So sollen neben dem Jαuß-Compiler im engeren Sinne z.B. auch Konverter zur Erzeugung von CAP-Dateien (Card Application Files) und Optimierungsprogramme als "Compiler" bezeichnet werden.
Eine Quellprogrammanalyse zur Compilezeit kann in der Regel nur ein ungefähres Ergebnis liefern. Darunter ist zu verstehen, daß zumindest eine der beiden Klassifizierungen eines Objekts als lokal bzw. nicht-lokal mit einer gewissen Unsicherheit behaftet ist. Es kann deshalb vorgesehen sein, daß nur sicher als lokal erkannte Objekte im zweiten Speicherbereich angelegt werden, während alle anderen Objekte im ersten Speicherbereich angelegt werden. In einer Ausführungsalternative werden dagegen nur die sicher als nicht-lokal erkannten Objekte im ersten Speicherbereich angelegt, während alle anderen Objekte im zweiten Speicherbereich angelegt werden. Zumindest für Objekte, die nicht sicher als lokal klassifiziert werden konnten, wird dann zusätzlich die oben beschriebene Lauf Zeitüberwachung durchgeführt. In manchen Ausführungsformen sind Compilerdirektiven (pragmas) . vorgesehen, mit denen Objekte als lokal oder nicht-lokal gekennzeichnet werden können.
In bevorzugten Ausgestaltungen werden - wahlweise zur Laufzeit oder zur Compilezeit - einfache Kriterien angewendet, um zu bestimmen, ob Objekte im ersten oder zunächst im zweiten Speicherbereich angelegt werden sollen. So kann z.B. vorgesehen sein, daß Objekte, die durch die znsrαH-Methode des Programms erzeugt werden, im ersten Speicherbereich angelegt werden. In unterschiedlichen Ausführungsformen können entweder alle anderen Objek- te zunächst im zweiten Speicherbereich angelegt werden oder nur einzelne Arten von Objekten. Solche Objektarten können z.B. exception-Ob]ekte oder Objekte sein, die nur temporär für kryptographische Operationen benötigt werden.
Die Lebensdauer eines lokalen Objekts endet in der Regel mit der Beendigung - entweder durch einen Rücksprung (return) oder durch eine Ausnahme (exception) - der Methode, in der das lokale Objekt erzeugt worden ist, weil zu diesem Zeitpunkt die möglicherweise existierenden lokalen Referenzen auf das Objekt gelöscht werden. Der gegebenenfalls im zweiten Spei- cherbereich für das Objekt noch benötigte Speicherplatz kann dann freigegeben werden. Eine Ausnahme von der gerade genannten Regel gilt dann, wenn das Objekt als Rückgabeparameter der Methode, die das Objekt erzeugt hat, verwendet wird. Die aufrufende Methode erhält in diesem Fall eine Referenz auf das Objekt, so daß das Objekt zumindest bis zur Beendi- gung dieser Methode nicht gelöscht werden darf .
Um freigegebenen Speicherplatz im zweiten Speicherbereich zur Anlage neuer Objekte nutzen zu können, ist in manchen Ausführungsformen eine Speicherbereinigung (garbage collectio ) vorgesehen. Diese verursacht jedoch Zeitaufwand während der Programmausführung und erhöht die Komplexität der Laufzeitumgebung. Bevorzugt wird daher ein besonders einfaches Verfahren eingesetzt, bei dem ein Füllstandszeiger die Belegung des zweiten Speicherbereichs angibt. Bei der Beendigung einer Methode wird der Füllstandszeiger in der Regel auf den Stand zurückgesetzt, den er beim Aufruf dieser Methode hatte. Eine Ausnahme von dieser Regel wird in bevorzugten Ausführungsformen lediglich dann gemacht, wenn der durch die Rücksetzung freigegebene Abschnitt des zweiten Speicherbereichs ein Objekt enthält, das als Rückgabeparameter der Methode verwendet wird.
Um zu gewährleisten, daß ein Objekt bei Bedarf vom zweiten in den ersten Speicherbereich übertragen werden kann, wird vorzugsweise schon beim Anlegen des Objekts im zweiten Speicherbereich überprüft, ob auch im ersten Speicherbereich genügend Platz für das Objekt vorhanden ist. Bevor- zugt wird auch während der weiteren Programmausführung beim Anlegen neuer Objekte sichergestellt, daß im ersten Speicherbereich stets genügend Platz für eine eventuell erforderliche Übertragung von Objekten ist.
Der erste Speicherbereich befindet sich in bevorzugten Ausgestaltungen in einem EEPROM oder eintem sonstigen nicht-flüchtigen beschreibbaren Speicher des Datenträgers, während der zweite Speicherbereich in einem RAM oder einem sonstigen effizient beschreibbaren Speicher angeordnet ist. Der zweite Speicherbereich kann insbesondere als lokaler Heap und/ oder in einem Stapelspeicher ausgebildet sein. Die Speicherung in einem Stapelspei- eher ist insbesondere für Objekte vorteilhaft, die schon zur Compilezeit als lokale Objekte identifiziert wurden.
Das erfindungsgemäße Computerprogrammprodukt weist Programmbefehle auf, um das erfindungsgemäße Umsetzungsverfahren zu implemen- tieren. Ein derartiges Computerprogrammprodukt kann ein körperliches Medium sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM, auf dem ein Programm zur Ausführung eines erfindungsgemäßen Verfahrens gespeichert ist. Das Computerprograrrvmprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Bevorzugt ist das Computerprogrammprodukt ein Compiler, der zur Ausführung durch einen üblichen Arbeitsplatzrechner vorgesehen ist, um Programme für tragbare Datenträger zu erzeugen.
In bevorzugten Ausgestaltungen weisen der Datenträger und/ oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/ oder den in den abhängigen Verfahrensansprüchen genannten Merkmalen entsprechen.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden genauen Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen hervor. Es wird auf die schematischen Zeichnungen verwiesen, in denen zeigen:
Fig. 1 ein Blockdiagramm eines tragbaren Datenträgers nach einem Ausführungsbeispiel der Erfindung,
Fig. 2 ein Flußdiagrarnm eines beim Anlegen eines neuen Objekts ausgeführ- ten Verfahrens,
Fig. 3 eine beispielhafte Darstellung der Speicherbelegung in einem Stapelspeicher und einem lokalen Heap während der Programrnausführung,
Fig. 4 ein FlulSdiagrarnm eines bei der Beendigung einer Methode ausgeführten Verfahrens, und
c Fig. 5 eine schematische Darstellung der Umsetzung eines Queπprogramms in ein ausführbares Programm. Der in Fig. 1 dargestellte Datenträger 10 ist im vorliegenden Ausführungsbeispiel als Chipkarte gemäß dem Java-Card-Standard ausgestaltet. Der Datenträger 10 weist auf einem einzigen Halbleiterchip einen Prozessor 12, mehrere in unterschiedlichen Technologien ausgestaltete Speicherfelder und eine Schnittstellenschaltung 14 zur kontaktlosen oder kontaktgebundenen Kommunikation auf. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein Festwertspeicher 16, ein nicht-flüchtiger beschreibbarer Speicher 18 und ein Schreib-/ Lese-Speicher 20 vorgesehen. Der Festwertspeicher 16 ist als rnaskenprogramrniertes ROM, der nicht-flüchtige Speicher 18 als elektrisch lösch- und programmierbares EEPROM und der Schreib-/ Lese- Speicher 20 als RAM ausgestaltet. Schreibvorgänge in den nicht-flüchtigen Speicher 18 sind relativ aufwendig und benötigen beispielsweise die dreißigfache Zeit von Schreibvorgängen in den Schreib-/ Lese-Speicher 20.
Im Festwertspeicher 16 - und zum Teil auch im nicht-flüchtigen Speicher 18 - sind Systemprogramme 22 enthalten, die zum Betrieb des Datenträgers 10 benötigt werden. In an sich bekannter Weise umfassen die Systemprogramme 22 ein Betriebssystem 24 sowie Programmcode 26 zur Implementierung einer virtuellen Maschine 26, die im vorliegenden Ausfülirungsbeispiel als JCVM (Jαvα Card Virtual Machine) ausgestaltet ist. Ferner ist eine Klassenbibliothek 28 vorgesehen, die Anwendungsprogramnrierschnittstellen bereitstellt. Ein Programm 30, das als Java Card Applet ausgebildet ist, wurde bei der Initialisierung des Datenträgers 10 in den nicht-flüchtigen Speicher 18 geladen; in Ausführungsalternativen kann sich das Programm 30 ganz oder teilweise im Festwertspeicher 16 befinden." Während in Fig. 1 nur ein einziges Programm 30 gezeigt ist, können weitere Programme zur Ausführung durch den Prozessor 12 des tragbaren Datenträgers 10 vorgesehen sein. Das Programm 30 weist mehrere Methoden 30.1, 30.2, 30.3, 30.4 auf, die im folgenden zusammenfassend mit 30.x bezeichnet werden. In an sich bekannter Weise umfassen die Methoden 30.x eine mit "install" bezeichnete Methode zur Installation des Programms 30, eine mit "process" bezeichnete Methode zur Bearbeitung eingehender Datenpakete und gegebenenfalls Methoden "select" und "deselect", die bei einem Wechsel zwischen mehreren Programmen des Datenträgers 10 aufgerufen werden.
Ein im Schreib-/ Lese-Speicher 20 befindlicher Stapelspeicher 32 nimmt wäh- rend der Programmausführung Operanden, Rücksprungädressen, lokale
Variablen und sonstige Datenwerte auf. Der freie Bereich des Stapelspeichers 32 ist in Fig. 1 durch eine Schraffur veranschaulicht.
Im nicht-flüchtigen Speicher 18 ist ein erster Speicherbereich 34 reserviert, der in an sich bekannter Weise als persistenter Heap (Haufen oder Halde) ausgebildet ist. Gemäß der üblichen Java-Card- Architektur würden in diesem persistenten Heap alle Objekte, statischen Datenfelder und nicht-transienten Arrays angelegt werden. Im vorliegenden Ausführungsbeispiel wird dagegen der persistente Heap nur selektiv eingesetzt. Lokale Objekte, die voraus- sichtlich nur eine kurze Lebensdauer besitzen und auf die keine persistenten Referenzen verweisen, werden nicht im ersten Speicherbereich 34, sondern in einem zweiten Speicherbereich 36 im Schreib-/ Lese-Speicher 20 angelegt. Der zweite Speicherbereich 36 wird auch als lokaler Heap bezeichnet, weil er ähnlich wie der persistente Heap zur Speicherung von Objekten dient.
Zur Veranschaulichung der gerade beschriebenen Verhältnisse zeigt Fig. 1 beispielhaft zwei im ersten Speicherbereich 34 angelegte Objekte 38, 0, die jeweils mehrere Datenfelder aufweisen. Eines der Datenfelder des ersten Objekts 38 enthält eine Referenz 42 auf das zweite Objekt 40. Die Referenz 42 wird, da sie in einem persistent gespeicherten Datenfeld enthalten ist, auch als "persistente Referenz" bezeichnet. Das zweite Objekt 40 ist kein lokales, sondern ein persistentes Objekt, da die persistente Referenz 42 darauf verweist. Im zweiten Speicherbereich 36 ist beispielhaft ein lokales Objekt 44 gezeigt. Eine lokale Referenz 46, die beispielsweise in einer im Stapelspeicher 32 angelegten lokalen Variablen enthalten ist, verweist auf das lokale Objekt 44. Ein weiterer Wert im Stapelspeicher 32 gibt als Füllstandszeiger 48 den Beginn des freien Speichers im zweiten Speicherbereich 36 an; dieser freie Speicher ist in Fig. 1 schraffiert dargestellt.
Wenn bei der Programmausführung durch den Datenträger 10 die Anlage eines neuen Objekts durch den Befehl "NEW angefordert wird, wird der in Fig. 2 dargestellte Ablauf ausgeführt. In Schritt 50 wird zunächst geprüft, ob im ersten Speicherbereich 34 genügend Speicherplatz zur Anlage des neuen Objekts frei ist. Ist zu wenig Speicherplatz vorhanden, so wird die Objekterzeugung mit einer Fehlermeldung abgebrochen. Die Überprüfung in Schritt 50 findet im vorliegenden Ausführungsbeispiel unabhängig von der Art des anzulegenden Objekts statt, um sicherzustellen, daß auch ein zunächst im zweiten Speicherbereich 36 angelegtes Objekt jederzeit in den ersten Speicherbereich 34 übertragen werden kann.
Im vorliegenden Ausführungsbeispiel ist vorgesehen, daß Objekte, die durch die Installationsmethode "install" des Programms 30 angelegt werden, stets als persistente Objekte betrachtet und daher in den ersten Speicherbereich 34 auf genommen werden. In Schritt 52 wird daher abgefragt, ob gerade die Programminstallation stattfindet. Ist dies der Fall, so wird das neue Objekt in Schritt 54 als persistentes Objekt im ersten Speicherbereich 34 erzeugt. Der in Schritt 54 ausgeführte Erzeugungsvorgang entspricht der bei einer üblichen Java Card ausgeführten Anlage eines Objekts im persistenten Heap. Wenn in Schritt 52 festgestellt wurde, daß sich die Programmausführung außerhalb der Installationsmethode befindet, wird das neu anzulegende Objekt im vorliegenden Ausführungsbeispiel zunächst als lokales Objekt angesehen. Es wird dann im zweiten Speicherbereich 36 - dem lokalen Heap - angelegt, sofern dort genügend Speicherplatz frei ist. Letzteres wird in Schritt 56 überprüft. Ist genügend Speicherplatz im lokalen Heap vorhanden, wird das Objekt dort in Schritt 58 an der nächsten freien Stelle - unmittelbar anschließend an den bisher genutzten Bereich - angelegt, und der Füll- standszeiger 48 wird entsprechend aktualisiert. Ist der lokale Heap dagegen bereits zu voll, so erfolgt in Schritt 54 der übliche Objektanlagevorgang im ersten Speicherbereich 34, in dem ja - wie in Schritt 50 überprüft - noch genügend freier Speicherplatz verfügbar ist.
Während der weiteren Ausführung des Programms 30 durch den Datenträger 10 wird bei jeder Erzeugung oder Änderung einer persistenten Referenz überprüft, ob die Referenz auf ein im zweiten Speicherbereich 36 befindliches Objekt verweist. Ist dies der Fall, so wird das Objekt aus dem zweiten ' Speicherbereich 36 in den ersten Speicherbereich 34 übertragen. Wegen der Abfrage in Schritt 50 ist sichergestellt, daß dies jederzeit möglich ist.
Im vorliegenden Ausführungsbeispiel ist der zweite Speicherbereich 36 ähnlich wie ein Stapelspeicher organisiert, um nach Beendigung einer Methode 30.x den Speicherplatz, der durch die in dieser Methode 30.x erzeugten loka- len Objekte belegt wird, auf einfache Weise freigeben zu können. Zur Erläuterung dieses Vorgangs zeigt Fig. 3 eine beispielhafte Belegung des Stapelspeichers 32 mit mehreren Stapelrahmen (stach frames) 60.1, 60.2, 60.3. In an sich bekannter Weise wird beim Aufruf jeder Methode 30.x ein neuer Stapelrahmen 60.x angelegt, der bei Beendigung der Methode 30.x wieder gelöscht wird. Der Stapelrahmen 60.x enthält eine Rücksprungadresse zur aufrufenden Methode, Verwaltungs- und Sicherungsdaten sowie gegebenenfalls lokale Variablen der aufgerufenen Methode.
Im vorliegenden Ausführungsbeispiel weist jeder Stapelrahmen 60,x ferner ein Füllstandsfeld 62.x auf, das während der Ausführung der entsprechenden Methode 30.x den Füllstandszeiger 48 enthält. In der beispielhaften Darstellung von Fig. 3 enthält also das Füllstandsfeld 62.3 den aktuellen Füllstandszeiger 48, und das Füllstandsfeld 62.2 enthält denjenigen Füllstand, der beim Aufruf der dem Stapelrahmen 60.3 entsprechenden Methode gegolten hat. Der Abschnitt 64.3 bezeichnet denjenigen Abschnitt im lokalen Heap, der von der aktuell ausgeführten Methode seit ihrem Aufruf neu belegt wurde. Die Abschnitte 64.1 und 64.2 im lokalen Heap wurden von denjenigen Methoden, bei deren Aufruf die Speicherrahmen 60.1 bzw. 60.2 angelegt wurden, gefüllt.
Im vorliegend beschriebenen Ausführungsbeispiel ist vorgesehen, daß bei der Beendigung einer Methode der durch diese Methode belegte Platz im zweiten Speicherbereich 36 in der Regel vollständig freigegeben wird. Dies geschieht ohne weiteres Zutun dadurch, daß bei der Beendigung einer Methode der entsprechende Stapelrahmen 60.x - einschließlich des darin enthaltenen Füllstandsfeldes 62.x - verworfen wird, und daß das Füllstandsfeld 62.(x-l) des nächstälteren Stapelrahmens 62.(x-l) mit seiner dort gespeicherten Belegung als neuer Füllstandszeiger 48 verwendet wird. So wird beispielsweise nach der Beendigung derjenigen Methode, bei deren Aufruf der Stapelrahmen 60.3 angelegt wurde, der Inhalt des Füllstandsfeldes 62.2 als neuer Füllstandszeiger 48 verwendet, so daß der gesamte Speicherabschnitt 64.3 freigegeben wird. Eine Ausnahme von der im vorherigen Absatz genannten Regel ergibt sich dann, wenn die gerade beendete Methode eine Referenz auf ein von ihr im zweiten Speicherbereich 36 angelegtes lokales Objekt an die aufrufende Methode zurückgibt. In diesem Fall wird der Inhalt des aktuellen Füllstands- feldes 62.x in den nächstälteren Stapelrahmen 60.(x-l) kopiert, um ein Überschreiben des lokalen Objekts zu verhindern. Wenn beispielsweise bei der Speicherbelegung von Fig. 3 die Methode, die den Speicherrahmen 60.3 angelegt hat, einen Verweis auf ein im Speicherbereich 64.3 befindliches Objekt zurückgibt, wird der Wert des Füllstandsfeldes 62.3 in das Füllstandsfeld 62.2 des vorhergehenden Stapelrahmens 60.2 kopiert.
Das gerade geschilderte Verfahren bei der Beendigung einer Methode ist in Fig. 4 nochmals veranschaulicht. In Abhängigkeit vom Ergebnis des Schrittes 70 wird entweder das Füllstandsfeld 62.(x-l) des vorhergehenden Stapel- rahmens 60.(x-l) reaktiviert (Schritt 72), oder es wird der Wert des aktuellen Füllstandszeigers 48 in den vorhergehenden Stapelrahmen 60.(x-l) übernommen.
In Fig. 5 ist der an sich bekannte Übersetzungsvorgang eines J uα-Quellpro- gramms 80 durch einen Compiler 82 in eine CAP-Datei (Card Application File) 84 dargestellt. Die CAP-Datei 84 wird ihrerseits von einem Ladeprogramm 86 - z.B. bei der Initialisierung des Datenträgers 10 - als Programm 30 in den Datenträger 10 geladen. Der Compiler 82 weist im hier beschriebenen Aus- führungsbeispiel neben dem eigentlichen Compiliermodul zur Übersetzung des Quellprogramms 80 in Bytecode ferner einen Konverter auf, der diverse Korrektheitsüberprüfungen vornimmt und der auch als "Off-Card Virtual Machine" bezeichnet wird. Bei dem bislang beschriebenen Verfahren wurde zur Entscheidung, ob ein neu anzulegendes Objekt im ersten oder im zweiten Speicherbereich 34, 36 erzeugt werden sollte, zur Laufzeit in Schritt 52 eine einfache Abfrage durchgeführt. Weitere Laufzeitüberprüfungen erfolgten bei der Anlage und bei Aktualisierungen von persistenten Referenzen. In Ausführungsalternativen ist dagegen vorgesehen, die genannten Überprüfungen ganz oder zum Teil auf die Ebene des Compilers 82 vorzuverlagern.
Durch abstrakte Analyse des Quellprogramms 80 oder eines Zwischencodes kann der Compiler 82 Informationen gewinnen, ob ein während der späteren Programrnausführung neu anzulegendes Objekt als lokales oder als nichtlokales Objekt betrachtet werden soll. Je nach dem Ergebnis dieser Analyse erzeugt der Compiler 82 dann Programmcode, der entweder die Anlage des Objekts im ersten Speicherbereich 34 oder im zweiten Speicherbereich 36 bewirkt. In Ausführungsalternativen werden Objekte, die zur Compilezeit sicher als lokal erkannt wurden, wie lokale Variablen im Stapelspeicher 32 angelegt. Je nachdem, ob zusätzlich ein lokaler Heap im Schreib-/ Lese-Speicher 20 vorgesehen ist, bildet in diesen Ausgestaltungen der Stapelspeicher 32 den gesamten zweiten Speicherbereich 36 oder einen Teil des zweiten Speicherbereichs 36.
In der Regel wird das Quellprogramm 80 Befehle zur Erzeugung von Objekten erhalten, die zur Compilezeit nicht eindeutig als lokale oder nicht-lokale Objekte klassifiziert werden können. Solche Objekte können entweder so- gleich im ersten Speicherbereich 34 angelegt werden, oder sie können auf die oben beschriebene Weise zunächst als lokale Objekte im zweiten Speicherbereich 36 angelegt und nur bei Bedarf in den ersten Speicherbereich 34 übertragen werden.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Speicherverwaltung bei der Ausführung eines Programms (30) durch einen tragbaren Datenträger (10), der einen ersten und einen zweiten Speicherbereich (34, 36) zur Speicherung von bei der Programmausführung erzeugten Objekten (38, 0, 44) aufweist, wobei Schreibvorgänge in den zweiten Speicherbereich (36) effizienter ausgeführt werden als Schreibvorgänge in den ersten Speicherbereich (34), mit den Schritten: - Anlegen eines bei der Programmausführung erzeugten Objekts
(38, 0, 44) zumindest zum Teil im zweiten Speicherbereich (36), und
Übertragen des Objekts (38, 40, 44) in den ersten Speicherbereich (34), falls im Zuge der weiteren Programmausführung eine per- sistente Referenz (42) auf das Objekt (38, 40, 44) erzeugt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Objekt (38, 0, 44) während der Ausführung einer Methode (30.x) des Programms (30) erzeugt wird>.und daß bei Beendigung dieser Methode (30.x) der von dem Objekt (38, 40, 44) gegebenenfalls noch belegte Speicherplatz im zweiten Speicherbereich (36) zumindest dann freigegeben wird, wenn die Methode (30.x) keine Referenz auf das Objekt (38, 40, 44) zurückgibt.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß bei
Beendigung der Methode (30.x) ein Füllstandszeiger (48), der die Belegung des zweiten Speicherbereichs (36) anzeigt, zumindest dann auf den beim Aufruf der Methode (30.x) geltenden Stand zurückgesetzt wird, wenn die Methode (30.x) keine Referenz auf ein im zweiten Speicherbereich (36) befindliches Objekt (38, 40, 4) zurückgibt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekenn- zeichnet, daß beim Anlegen eines Objekts (38, 0, 44) im zweiten
Speicherbereich (36) überprüft wird, ob im ersten Speicherbereich (34) genügend Platz für eine gegebenenfalls erforderliche Übertragung des Objekts (38, 40, 44) vorhanden ist.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß Objekte (38, 40, 44), die während der Installation des Programms (30) erzeugt werden, im ersten Speicherbereich (34) angelegt werden.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß nur Objekte (38, 40, 44), die bei der Erzeugung des Programms (30) aus einem Quellprogramm (80) als lokale Objekte identifiziert wurden, zunächst im zweiten Speicherbereich (36) angelegt werden.
7. Verfahren zum Umsetzen eines Quellprogramms (80) in ein zur Ausführung durch einen tragbaren Datenträger (10) vorgesehenes Programm (30), wobei der Datenträger (10) einen ersten und einen zweiten Speicherbereich (34, 36) zur Speicherung von bei der Pro- grammausführung erzeugten Objekten (38, 40, 44) aufweist und wobei Schreibvorgänge in den zweiten Speicherbereich (36) effizienter ausgeführt werden als Schreibvorgänge in den ersten Speicherbereich (34), dadurch gekennzeichnet, daß bei der Umsetzung eines Abschnitts des Quellprogramms (80), der die Erzeu- gung eines Objekts (38, 40, 44) beinhaltet, zumindest ungefähr überprüft wird, ob in dem umgesetzten Abschnitt des Quellprogramms (80) eine persistente Referenz (42) auf das Objekt (38, 40, 44) erzeugt wird, und daß in Abhängigkeit von dem Ergebnis dieser Überprüfung entweder Programmcode erzeugt wird, der das Objekt (38, 40, 4) im ersten Speicherbereich (34) anlegt, oder Programmcode erzeugt wird, der das Objekt (38, 0, 44) zumindest zum Teil im zweiten Speicherbereich (36) anlegt.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß das erzeugte Programm (30) dazu eingerichtet ist, bei der Ausführung durch den tragbaren Datenträger (10) ein Verfahren nach einem der Ansprüche 1 bis 6 auszuführen.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß das im zweiten Speicherbereich (36) angelegte Objekt (38, 0, 44) ein lokales und nur temporär benötigtes Objekt ist.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekenn- zeichnet, daß der zweite Speicherbereich (36) einen lokalen Heap und/ oder einen Stapelspeicher (32) umfaßt.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß der Datenträger (10) eine Java Card ist, und daß das Programm (30) ein Java Card Applet ist.
12. Tragbarer Datenträger (10), insbesondere Chipkarte oder Chipmodul, mit einem Prozessor (12) und mindestens einem Speicher (16, 18, 20), wobei der Speicher (16, 18, 20) Programmbefehle ent- hält, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 6 veranlassen.
13. Computerprogrammprodukt, insbesondere Compiler (82), das Programmbefehle aufweist, die einen Computer veranlassen, ein Verfahren mit den Merkmalen von Anspruch 7 oder Anspruch 8 auszuführen.
EP04730985A 2003-05-06 2004-05-04 Speicherverwaltung bei einem tragbaren datentrager Withdrawn EP1623394A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10320062A DE10320062A1 (de) 2003-05-06 2003-05-06 Speicherverwaltung bei einem tragbaren Datenträger
PCT/EP2004/004723 WO2004100090A1 (de) 2003-05-06 2004-05-04 Speicherverwaltung bei einem tragbaren datenträger

Publications (1)

Publication Number Publication Date
EP1623394A1 true EP1623394A1 (de) 2006-02-08

Family

ID=33426673

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04730985A Withdrawn EP1623394A1 (de) 2003-05-06 2004-05-04 Speicherverwaltung bei einem tragbaren datentrager

Country Status (6)

Country Link
US (1) US8819373B2 (de)
EP (1) EP1623394A1 (de)
JP (2) JP2006525568A (de)
CN (1) CN1781127B (de)
DE (1) DE10320062A1 (de)
WO (1) WO2004100090A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100801894B1 (ko) * 2006-06-15 2008-02-12 삼성전자주식회사 휴대용 단말기에서 메모리 용량을 고려한 프로그램 실행을위한 장치 및 방법
DE102006034375A1 (de) * 2006-07-25 2008-01-31 Giesecke & Devrient Gmbh Personalisierung von tragbaren Datenträgern
US8917165B2 (en) * 2007-03-08 2014-12-23 The Mitre Corporation RFID tag detection and re-personalization
US9196346B2 (en) * 2008-01-23 2015-11-24 Micron Technology, Inc. Non-volatile memory with LPDRAM
EP2196934A1 (de) * 2008-12-09 2010-06-16 Gemalto SA Verfahren zur Sicherung des Java-Bytecodes
JP6013103B2 (ja) * 2012-09-20 2016-10-25 株式会社東芝 Ｉｃカード
CN108140100B (zh) * 2015-10-28 2021-10-08 赫尔实验室有限公司 维护对象的安全标签和引用计数的系统、方法和介质
JP7397179B2 (ja) * 2019-12-20 2023-12-12 インテル・コーポレーション 階層化オブジェクトメモリ配置のためのランタイム装置の管理
DE102022001682A1 (de) * 2022-05-12 2023-11-16 Giesecke+Devrient ePayments GmbH Secure Element mit Heap-Speicher

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4829169A (en) * 1985-07-01 1989-05-09 Toppan Moore Company, Inc. IC card having state marker for record access
EP0955577B1 (de) 1998-05-04 2011-11-30 International Business Machines Corporation Verfahren und Vorrichtung zum Erzeugen eines Objektes in einem nicht dauerhaften Speicher und/oder Halten des Zugangs zu besagtem Objekt
DE69817333T2 (de) * 1998-06-05 2004-06-09 International Business Machines Corp. Verfahren und Vorrichtung zum Laden von Befehlskodes in einen Speicher und zum Verbinden dieser Befehlskodes
JP3749798B2 (ja) 1998-12-01 2006-03-01 株式会社東芝 Ｉｃカードにおけるデータ書込方法およびｉｃカードにおけるデータ読込方法
JP2001067210A (ja) * 1999-08-30 2001-03-16 Toshiba Corp Ｉｃカードとｉｃカードにおけるアプリケーションのインストール方法
EP1239411B1 (de) * 1999-11-30 2006-09-06 Kabushiki Kaisha Toshiba Chipkarte und verfahren zur verwaltung eines flüchtigen speichers auf derselben
DE10040974A1 (de) * 2000-08-22 2002-03-14 Giesecke & Devrient Gmbh Verfahren zur virtuellen Vergrößerung des Stacks eines tragbaren Datenträgers

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2004100090A1 *

Also Published As

Publication number Publication date
US8819373B2 (en) 2014-08-26
US20070016744A1 (en) 2007-01-18
JP2006525568A (ja) 2006-11-09
JP5457496B2 (ja) 2014-04-02
DE10320062A1 (de) 2004-12-16
JP2012164350A (ja) 2012-08-30
WO2004100090A1 (de) 2004-11-18
CN1781127A (zh) 2006-05-31
CN1781127B (zh) 2010-10-20

Similar Documents

Publication Publication Date Title
DE60032694T2 (de) Speicherrückforderungsverfahren
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE69429305T2 (de) System und Verfahren für Sprachenverarbeitung
WO1997001147A2 (de) Verfahren zur vereinfachung der kommunikation mit chipkarten
DE19581754B4 (de) System und Verfahren zum bedingten Kompilieren einer Software-Kompiliereinheit
EP1623394A1 (de) Speicherverwaltung bei einem tragbaren datentrager
DE60318993T2 (de) Eingebettete Speicherbereinigung
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
DE69328664T2 (de) Verfahren und Anordnung zur Zusammenbindung von Objekten
DE10102202A1 (de) Mikroprozessorschaltung für tragbare Datenträger
EP1695207A2 (de) Java smart card chip mit für globale variablen reserviertem speicherbereich
EP1709534B1 (de) Ausführung eines programms durch eine virtuelle maschine
DE10324384B3 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
DE102004040296B3 (de) Schreiben von Daten in einen nichtflüchtigen Speicher eines tragbaren Datenträgers
DE19637883B4 (de) Datenverarbeitungsanlage zur Ausführung großer Programmsysteme
DE102004006308B4 (de) Verfahren zum Verändern von Programmcode eines tragbaren Datenträgers mittels Patchdaten
EP1600855B1 (de) Erzeugen und Verwenden von Speicherbelegungsinformationen bei einem tragbaren Datenträger
EP1728162A1 (de) Speicherbereinigung (garbage collection) für smart cards
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
DE102022001682A1 (de) Secure Element mit Heap-Speicher
DE102008044808B4 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers
DE102004014885B4 (de) Verfahren zur Optimierung eines Programms eines tragbaren Datenträgers
DE19807191A1 (de) Programmablaufverfahren und Verfahren zur Erweiterung eines Programmkomponentensystems
DE102008057682A1 (de) Verfahren zum Optimieren von Programmcode für einen tragbaren Datenträger
DE10249597A1 (de) Steuern eines Speicherbereinigungsvorgangs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051206

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: KRAMPOSTHUBER, GEORG

Inventor name: STOCKER, THOMAS

17Q First examination report despatched

Effective date: 20070903

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20180718

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20181201