Die Erfindung betrifft einen für eine objektorientierte Programmiersprache einge¬ richteten Datenträger, insbesondere einen Chip, ein Chipmodul bzw. eine Chipkarte mit einem solchen Chip oder Chipmodul, mit einem Mikroprozessor, mit einem nichtflüchtigen Anwendungsspeicher (EEPROM) für Programmcode enthaltende Pakete und Daten enthaltende Objekte, und mit einer Speicherverwaltung zum Ver¬ walten des nichtflüchtigen Anwendungsspeichers (EEPROM).

Insbesondere betrifft die Erfindung einen solchen Datenträger in Ausgestaltung einer Java Card, der dazu eingerichtet ist, Programme in der objektorientierten Program¬ miersprache Java™ (Sun Microsystems) abzuarbeiten, insbesondere durch eine in dem Datenträger implementierte virtuelle Java-Card-Maschine.

Der Datenträger kann einen Körper in jeder beliebigen äußeren Form haben, z.B. in standardisierter (z.B. ISO) oder nicht-standardisierter Scheckkartenform, in Form eines volumigen Tokens oder in Form eines Chipmoduls.

Ein Datenträger hat typischerweise einen Mikroprozessor, mehrere Speicher und wahlweise ein oder mehrere Schnittstellen für kontaktlose und/oder kontaktbehaftete Kommunikation zwischen dem Datenträger und äußeren Einrichtungen. Als Speicher hat der Datenträger einen nichtflüchtigen Systemspeicher (ROM und/oder ggf. Flash- Speicher), einen nichtflüchtigen Anwendungsspeicher (EEPROM und/oder ggf. weiterer Flash-Speicher) und einen flüchtigen Arbeitsspeicher (RAM).

Im Folgenden wird, gemäß der am häufigsten verwendeten Ausführungsform eines Datenträgers wie z.B. einer Java Card, der nichtflüchtige Systemspeicher als ROM bezeichnet, der nichtflüchtige Anwendungsspeicher als EEPROM und der flüchtige Arbeitsspeicher als RAM, auch wenn die Speicher (insbesondere ROM, EEPROM) ganz oder teilweise in anderen Technologien (z.B. Flash) verwirklicht sein können.

Bei einem herkömmlichen für eine objektorientierte Programmiersprache eingerich¬ teten Datenträger (z.B. Java Card) wird Programmcode, z.B. für Systemfunktionen oder für Anwendungen, in Form von Paketen (packages) in den Datenträger geladen. Zusätzlich zum Programmcode kann jedes Paket weitere Komponenten enthalten wie z.B. eine Export-Komponente, die den Zugriff von außerhalb des Pakets auf das Pa¬ ket regelt. Die Pakete werden statisch, d.h. vor der Laufzeit (vor dem Ablaufenlas- sen) des jeweiligen Programms in den Datenträger geladen und dort in einem dafür vorgesehenen Speicher (z.B. ROM, EEPROM) abgespeichert.

Zur Laufzeit des Programms werden aus dem zugehörigen Paket heraus dynamisch Objekte angelegt, in denen Daten enthalten sind.

Im ROM des herkömmlichen für eine objektorientierte Programmiersprache einge¬ richteten Datenträgers ist vor allem das Betriebssystem abgespeichert, und zudem ggf. Pakete (packages) mit Systemfunktionen, oder sog. preloaded packages, d.h. Pakete, die vor der Komplettierung des Datenträgers in den Datenträger geladen werden.

Der EEPROM des herkömmlichen für eine objektorientierte Programmiersprache eingerichteten Datenträgers enthält unter Anderem einen im Wesentlichen für Pro¬ grammcode vorgesehenen Paketspeicher, in dem Pakete (packages) mit Programm- code und ggf. weiteren Komponenten (z.B. Export-Komponente) abgespeichert sind.

Weiter enthält der herkömmliche EEPROM für Daten einen Heap- Speicher, in dem zur Laufzeit eines jeweiligen aufgerufenen Programms dynamisch Objekte angelegt werden, in denen Daten enthalten sind. Durch das dynamische Anlegen eines jewei- ligen Objekts im Heap-Speicher wird im Heap-Speicher der für das Objekt erforder¬ liche Speicherplatz dynamisch allokiert (zugewiesen).

Wahlweise werden im EEPROM zudem Systemvariablen angelegt.

Durch die Aufteilung des EEPROM in einen Heap-Speicher für Objekte, d.h. Daten, und einen Paketspeicher für Programmcode ist die Speicherverwaltung unflexibel. Insbesondere kann dadurch, dass zwei starr getrennte Speicherbereiche vorhanden sind, der vorhandene Speicherplatz im EEPROM nicht optimal ausgenutzt werden, und die Wahrscheinlichkeit, dass der Speicher fragmentiert ist, ist hoch.

Wahlweise ist es bei einem herkömmlichen EEPROM vorgesehen, dass die Spei¬ chergrenze zwischen dem Paketspeicher für Programmcode und dem Heap-Speicher für Objekte, d.h. Daten, bei Bedarf mittels einer dazu vorgesehenen Speicherver¬ waltung verschiebbar ist, um den Speicherplatz im EEPROM möglichst effizient auszunutzen.

Ein weiterer Nachteil des zweigeteilten EEPROM ist, dass er heterogen ist, da der Paketspeicher und der Heap-Speicher unterschiedliche Anforderungen an die Spei- ■ cherverwaltung stellen, wodurch die Speicherverwaltung des herkömmlichen zwei¬ geteilten EEPROM umständlich ist.

Genauer verfügt der Heap-Speicher, auf dem die Objekte dynamisch angelegt wer¬ den, häufig (bei Java Cards z.B. bei den Versionen 2.2 und 3.0) über eine automati¬ sche Speicherbereinigung (Garbage Collection), die nicht mehr benötigten Heap- Speicher wieder freigibt. Manche Verfahren bzw. Einrichtungen zur automatischen Speicherbereinigung, z.B. Copy Collector oder Compacting Collector, defragmentie¬ ren den Heap-Speicher zusätzlich.

Der Paketspeicher, in dem Pakete statisch abgespeichert werden, benötigt eine zweite Implementierung einer automatischen Speicherbereinigung, um den Speicher optimal zu nutzen.

Aufgabe der Erfindung ist es, einen für eine objektorientierte Programmiersprache eingerichteten Datenträger mit einem Mikroprozessor und einem nichtflüchtigen Anwendungsspeicher (z.B. EEPROM) für Pakete und Objekte und mit einer einfa- chen, effizienten Speicherverwaltung für den Anwendungsspeicher zu schaffen. Die Aufgabe wird durch einen Datenträger nach dem unabhängigen Anspruch 1 ge¬ löst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.

Der erfindungsgemäße Datenträger gemäß dem unabhängigen Anspruch 1 ist für eine objektorientierte Programmiersprache eingerichtet, ist also beispielsweise eine Java Card mit einer virtuellen Java-Card-Maschine. Der Datenträger ist ausgestattet mit einem Mikroprozessor, einem nichtflüchtigen Anwendungsspeicher (z.B. EEPROM, Flash) für Pakete und Objekte in der objektorientierten Programmiersprache und mit einer Speicherverwaltung zum Verwalten des nichtflüchtigen Anwendungsspeichers. In den Paketen ist ablauffähiger Programmcode enthalten. Die Objekte werden zur Laufzeit des Programms, das dem Programmcode in dem Paket entspricht, dyna¬ misch angelegt. In den Objekten sind im Wesentlichen Daten enthalten, die zur Lauf¬ zeit eines jeweiligen Programms, d.h. sobald ein Programm aufgerufen wird, erzeugt werden.

Gemäß der Erfindung sind auch Pakete als Objekte angelegt, so dass Pakete und Ob¬ jekte in demselben einheitlichen Speicherbereich des Anwendungsspeichers angelegt werden können. Zur Verwaltung der Objekte, die nun Programmcode oder Daten enthalten können, ist daher nur eine einzige einheitliche Speicherverwaltung erfor¬ derlich, nämlich eine Speicherverwaltung, die Objekte verwalten kann. Mit anderen Worten existieren für die Speicherverwaltung im Anwendungsspeicher nur Objekte, die in einer für Objekte üblichen Weise durch die Speicherverwaltung verwaltet wer¬ den. Hierdurch ist durch die Erfindung der Verwaltungsaufwand bei der Speicher- Verwaltung verringert, und die Speicherverwaltung kann effizienter arbeiten.

Daher ist gemäß Anspruch 1 ein für eine objektorientierte Programmiersprache ein¬ gerichteter Datenträger mit einem Mikroprozessor und einem nichtflüchtigen An¬ wendungsspeicher für Pakete und Objekte geschaffen, der eine besonders einfache und effiziente Speicherverwaltung für den nichtflüchtigen Anwendungsspeicher hat. Zudem benötigt der durch die Speicherverwaltung verwaltete Anwendungsspeicher keine Speichergrenze, die verwaltet werden müsste. Denn da die Pakete als Objekte angelegt sind, ist eine Unterteilung des Anwendungsspeichers in einen Bereich für Pakete (im Wesentlichen Programmcode und ggf. weitere Komponenten wie Export- Komponenten) einerseits und Objekte (im Wesentlichen Daten) andererseits nicht erforderlich. Vorzugsweise ist der durch die Speicherveraltung verwaltete Anwen¬ dungsspeicher auch ein einheitlicher Speicherbereich ohne Speichergrenze (d.h. ohne innere Speichergrenze innerhalb des von der Speicherverwaltung verwalteten An¬ wendungsspeichers). Der Wegfall der Speichergrenze hat einerseits einen verringer- ten Verwaltungsaufwand zur Folge. Zum Anderen lässt sich der Anwendungsspei¬ cher effizienter ausfüllen, so dass die Speicherressourcen des Anwendungsspeichers effizient genutzt sind und die Gefahr einer Fragmentierung geringer ist.

Vorzugsweise ist der von der Speicherverwaltung verwaltete Anwendungsspeicher ein - insbesondere dynamisch zu allokierender - Heap-Speicher.

Gemäß einer bevorzugten Variante ist das Paket genauer als ein oder mehrere Ob¬ jekte vom Feldtyp (Array Type Object) angelegt. Ein solches Objekt vom Feldtyp ist ein Datenfeld (Array) mit einer Mehrzahl von Feldelementen (Array Elements). In den Feldelementen ist der Inhalt des Pakets abgelegt. Insbesondere, bei einer Java Card gemäß dieser Variante, ist das Paket vorzugsweise in Form eines Java Byte Array angelegt, das heißt in Form eines Datenfeldes (Array) mit einer Mehrzahl von einzelnen Feldelementen, die jeweils ein Byte (8 Bit) lang (groß) sind, bzw. in Form mehrere solcher Java Byte Arrays.

Gemäß einer bevorzugten Weiterbildung der Erfindung weist der Datenträger weiter eine Einrichtung zur automatischen Speicherbereinigung (Garbage Collection) auf, die zur automatischen Speicherbereinigung des von der Speicherverwaltung verwal¬ teten Anwendungsspeichers eingerichtet ist. Beispiele von verwendeten automati- sehen Speicherbereinigungen sind Mark and Sweep Garbage Collection und Ab¬ wandlungen davon. Die automatische Speicherbereinigung beseitigt bei der bevor- zugten Weiterbildung der Erfindung bei Bedarf nicht nur nicht mehr benötigte Daten (herkömmliche Objekte), sondern zusätzlich auch nicht mehr benötigten Programm¬ code und ggf. Exportkomponenten oder sonstige Paket-Bestandteile, die ja nach au¬ ßen hin ebenfalls als Objekte gestaltet sind. Es ist keine spezielle Speicherbereini- gung zur Beseitigung nicht mehr benötigter Pakete erforderlich. Aus diesem Grund ist die Speicherverwaltung gemäß der bevorzugten Weiterbildung insbesondere bei der automatischen Speicherbereinigung (Garbage Collection) besonders effizient.

Weiter kann der Datenträger eine Einrichtung zur Defragmentierung aufweisen, die zur Defragmentierung des von der Speicherverwaltung verwalteten Anwendungs¬ speichers eingerichtet ist.

Wahlweise ist die ggf. vorgesehene automatische Speicherbereinigung (Garbage Collection) zusätzlich zur Defragmentierung des Speicherbereichs eingerichtet. Bei- spielsweise wird als automatische Speicherbereinigung mit integrierter Defragmen¬ tierung ein Copy Collector oder ein Compacting Collector oder eine Abwandlung einer der beiden automatischen Speicherbereinigungen verwendet.

Vorzugsweise ist ein in dem Anwendungsspeicher abgespeichertes Paket als benutzt markiert, damit das Paket durch die Garbage Collection nicht gelöscht wird. Die Markierung des Pakets ist in einer für Objekte üblichen Weise vorgenommen, ent¬ sprechend dem Merkmal, dass das Paket als ein oder mehrere Objekte angelegt ist. Beispielsweise ist die Markierung im Objekt-Header enthalten. Die Markierung kann wahlweise in einer Registry des Anwendungsspeichers enthalten sein, die eine Auf- listung aller im Anwendungsspeicher enthaltenen Pakete enthält. Weiter vorzugswei¬ se wird, sobald ein Paket gelöscht wird, die Markierung des Pakets als benutzt wie¬ der aufgehoben.

Im folgenden wird die Erfindung anhand von Ausführungsbeispielen und unter Be- zugnahme auf die Zeichnung näher erläutert, in der zeigen: Fig. 1 eine schematische Darstellung eines Anwendungsspeichers EEPROM mit einem darin eingerichteten Heap- Speicher 101, gemäß einer Ausführungs- form der Erfindung;

Fig. 2 eine schematische Darstellung eines Anwendungsspeichers EEPROM gemäß dem Stand der Technik, mit einem Heap-Speicher 201 und einem Paketspei¬ cher 202, die durch eine verschiebbare Speichergrenze 203 voneinander ge¬ trennt sind;

Fig. 1 zeigt eine schematische Darstellung eines Anwendungsspeichers EEPROM gemäß einer Ausführungsform der Erfindung. Der EEPROM enthält eine Registry 110, eine Speicherverwaltung 120 (Memory Management) und einen Heap-Speicher 101. Der Heap-Speicher 101 ist einheitlich gestaltet und beherbergt sowohl her¬ kömmliche Objekte, d.h. Daten, als auch erfindungsgemäß als Objekte gestaltete Pakete, d.h. Programmcode (und ggf. Export-Komponenten etc.). In dem Heap- Speicher 101 sind genauer drei dynamisch angelegte herkömmliche Daten-Objekte 102, 103, 104 und ein, gemäß der Erfindung, als Byte Array Objekt gestaltetes Paket 105 angeordnet. Sowohl die Daten-Objekte 102, 103, 104 als auch das Paket-Objekt 105 sind für die Speicherverwaltung 120, die den Heap-Speicher 101 verwaltet, Ob- jekte.

Zum Vergleich zeigt Fig. 2 eine schematische Darstellung eines Anwendungsspei¬ chers EEPROM gemäß dem Stand der Technik, mit einem Heap-Speicher 201 und einem Paketspeicher 202, die durch eine verschiebbare Speichergrenze 203 vonein- ander getrennt sind. Der herkömmliche Heap-Speicher 201 ist den Daten vorbehalten und enthält nur dynamisch angelegte herkömmliche Objekte, hier die beiden Objekte 204 und 205. Pakete - und damit insbesondere Programmcode - sind hingegen in einem gesonderten Paketspeicher 202 abgespeichert, hier ist ein einzelnes Paket 206 im Paketspeicher 202 abgespeichert. Der Heap-Speicher 201 hat eine eigene Spei- cherverwaltung 21 1, und der Paketspeicher 202 hat ebenfalls eine eigene Speicher¬ verwaltung 212. Die Speichergrenze 203, die den Heap-Speicher 201 und den Paket- Speicher 202 voneinander trennt ist verschiebbar, damit die Speicheraufteilung bei Bedarf an die Speicherbedürfnisse eines ablaufenden Programms angepasst werden kann. Der EEPROM enthält ebenfalls eine Registry 210 (vgl. weiter unten).

Die in Fig. 1 dargestellte Art der Speicheraufteilung, die nur Objekte kennt, ist we¬ sentlich flexibler als die herkömmliche Art der Speicheraufteilung gemäß Fig. 2, die zwischen Objekten und Paketen unterscheiden muss, da bei der Speicheraufteilung gemäß Fig. 1 ein einheitlicher Speicherbereich ohne Speichergrenzen zu verwalten ist, in dem alle Speicherelemente 102, 103, 104, 105 nach „außen" hin für die Spei- cherverwaltung gleich aussehen, nämlich wie Objekte. Folglich kommt der einheitli¬ che Anwendungsspeicher 101, der nur Objekte kennt, mit einer einzigen einheitli¬ chen Speicherverwaltung 120 aus.

Bei einer Java Card ist eine Übersicht über sämtliche im EEPROM enthaltenen Pa- kete in der Registry des EEPROM enthalten. Für ein einzelnes Paket enthält die Re¬ gistry entweder einen einzelnen Eintrag oder - meistens - mehrere sogenannte Paket¬ daten-Einträge (Package Data Entries), die dem Programmcode und ggf. vorhande¬ nen weiteren Komponenten wie z.B. der Export-Komponente entsprechen. Trotz seiner Bezeichnung "Paketdaten-Eintrag" repräsentiert der Eintrag in der Registry nicht Daten, sondern Programmcode. Für den Programmcode eines einzelnen Pakets enthält die Registry in der Regel einen einzigen Paketdaten-Eintrag, alternativ auch mehrere Paketdaten-Einträge. Für in dem Paket eventuell vorhandene weitere Kom¬ ponenten wie z.B. Export-Komponenten enthält die Registry einen oder mehrere weitere Paketdaten-Einträge. Für Objekte mit Daten kann die Registry der Java Card einen oder mehrere Instanzen-Einträge haben. Paketdaten-Einträge zu implementier¬ ten Paketen sind in der Registry als benutzt markiert. Wird ein Paket gelöscht, wird die Markierung des Pakets gelöscht. Gemäß der Erfindung, bei der zu jedem Paket¬ daten-Eintrag ein Objekt angelegt ist, kann die Markierung als benutzt beispielsweise im Objekt-Header des Objekts, das dem Paketdaten-Objekt entspricht, enthalten sein. Soll nun ein Paket in den EEPROM einer Java Card implementiert werden, wird zuerst die Registry des EEPROM angelegt oder um das Paket ergänzt. Gemäß der Erfindung wird anschließend für jeden Paketdaten-Eintrag, der zu dem Paket in der Registry enthalten ist, ein Objekt im Heap-Speicher der Java Card angelegt. Hier- durch ist der Programmcode im EEPROM implementiert. Dennoch enthält der EEPROM lediglich Objekte, die durch die Speicherverwaltung einheitlich behandelt werden können. Sofern der Heap-Speicher über eine Garbage Collection (automati¬ sche Speicherbereinigung) verfügt, kann auch der Programmcode, der in Form von einem oder mehreren Objekten vorliegt, durch die Garbage Collection gepflegt wer- den, was bei herkömmlichen Verfahren bzw. Datenträgern nicht möglich ist.